From owner-ietf-smime Tue Jan 4 05:37:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA07221 for ietf-smime-bks; Tue, 4 Jan 2000 05:37:24 -0800 (PST) Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07217 for ; Tue, 4 Jan 2000 05:37:22 -0800 (PST) Received: by sentry; id IAA03632; Tue, 4 Jan 2000 08:38:27 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma003624; Tue, 4 Jan 00 08:38:18 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id IAA12377 for ietf-smime@imc.org; Tue, 4 Jan 2000 08:36:57 -0500 (EST) Date: Tue, 4 Jan 2000 08:36:57 -0500 (EST) From: "David M. Balenson" Message-Id: <200001041336.IAA12377@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: Jan. 6th early registration deadline for NDSS 2000 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: S A V E $ 7 0 O F F R E G I S T R A T I O N F E E ! ! R E G I S T E R B Y J A N U A R Y 6 , 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-smime Mon Jan 24 06:39:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA05128 for ietf-smime-bks; Mon, 24 Jan 2000 06:39:03 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05124 for ; Mon, 24 Jan 2000 06:39:01 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08480; Mon, 24 Jan 2000 09:40:27 -0500 (EST) Message-Id: <200001241440.JAA08480@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-smime@imc.org From: The IESG Subject: Document Action: Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME to Informational Date: Mon, 24 Jan 2000 09:40:27 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME' as an Informational RFC. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. From owner-ietf-smime Mon Jan 24 10:19:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA08613 for ietf-smime-bks; Mon, 24 Jan 2000 10:19:15 -0800 (PST) Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08609 for ; Mon, 24 Jan 2000 10:19:13 -0800 (PST) Received: by sentry; id NAA28292; Mon, 24 Jan 2000 13:22:05 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma028281; Mon, 24 Jan 00 13:21:11 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id NAA12546 for ietf-smime@imc.org; Mon, 24 Jan 2000 13:17:00 -0500 (EST) Date: Mon, 24 Jan 2000 13:17:00 -0500 (EST) From: "David M. Balenson" Message-Id: <200001241817.NAA12546@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: Last chance to register for NDSS 2000 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: L A S T C H A N C E - R E G I S T E R F O R N D S S 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 REGISTER ONLINE ON OR BEFORE WEDNESDAY, JANUARY 26 REGISTER ONSITE AFTER WEDNESDAY, JANUARY 26 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-smime Mon Jan 24 20:03:34 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA03055 for ietf-smime-bks; Mon, 24 Jan 2000 20:03:34 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA03050 for ; Mon, 24 Jan 2000 20:03:32 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Jan 2000 19:31:01 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Jan 2000 19:31:01 -0800 Message-ID: From: Jim Schaad To: =?iso-8859-1?Q?=27Pedro_F=E9lix=27?= , Tolga Acar , ietf-pkix@imc.org Cc: "Ietf-Smime (E-mail)" Subject: RE: Binding between keys and schemes? Date: Mon, 24 Jan 2000 19:30:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF66E4.98F2C2AA" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF66E4.98F2C2AA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My personal opinion on this issue is that in the absense of other = knowledge PKCS1-v1_5 would be used. If the S/MIME capabilities contained the OID = for OAEP, then it could be used instead. The certificate does not state = which scheme is to be used (just as it does not state that 3DES or RC5 should = be the bulk encryption algorithm used). =20 jim -----Original Message----- From: Pedro F=E9lix [mailto:pfelix@isel.pt] Sent: Friday, January 21, 2000 2:26 AM To: Tolga Acar; ietf-pkix@imc.org Subject: Re: Binding between keys and schemes? First of all, thanks for your reply. =20 I apologise for not making my question clear. When I asked about the binding between a key and a scheme, I was not refering to the scheme used to sign the certificate. =20 Let's supose that ALICE, running protocol P, want's to send a PKCS#7 Envelope to BOB, and has a X.509 certificate of BOB's public key (with rsaEncryption OID on the subjectPublicKeyInfo field). The certificate = was signed with scheme X (eg. DSA) and was correctly verified by ALICE = using that scheme. Which ENCRYPTION scheme should ALICE use to build the Envelope? ( RSAES-PKCS1-v1_5, RSAES-OAEP , ...) Probably ALICE would want to use the new RSAES-OAEP, but does BOB = support it? If I understood you correctly, this binding between the key and the = scheme IS NOT made by a X.509 certificate (except when the retation is 1-1) = and has to be built by other means (possibly defined by the protocol P). I'm I right? =20 I assume that the source of my initial confusion comes from the fact = that, in PKCS#1, the same OID (rsaEncryption) is used to identify both a key = and a encryption scheme. =20 =20 Once again, I thank you for your reply =20 Best regards =20 - Pedro Felix ------_=_NextPart_001_01BF66E4.98F2C2AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My=20 personal opinion on this issue is that in the absense of other = knowledge=20 PKCS1-v1_5 would be used.  If the S/MIME capabilities contained = the OID for=20 OAEP, then it could be used instead.  The certificate does not = state which=20 scheme is to be used (just as it does not state that 3DES or RC5 should = be the=20 bulk encryption algorithm used).
 
jim
-----Original Message-----
From: Pedro F=E9lix=20 [mailto:pfelix@isel.pt]
Sent: Friday, January 21, 2000 2:26 = AM
To: Tolga Acar; ietf-pkix@imc.org
Subject: Re: = Binding=20 between keys and schemes?

First of all, thanks for your = reply.
 
I apologise for not making my = question=20 clear.
When I asked about the binding between a key and a scheme, I was = not=20 refering to the scheme used to sign the certificate.
 
Let's supose that  ALICE, running protocol P, want's to = send a=20 PKCS#7 Envelope to BOB, and has a X.509 certificate of BOB's public = key=20 (with rsaEncryption OID on the subjectPublicKeyInfo field). The=20 certificate was signed with scheme X (eg. DSA) and was correctly = verified=20 by ALICE using that scheme.
Which ENCRYPTION scheme should ALICE use to build the = Envelope? (=20 RSAES-PKCS1-v1_5, RSAES-OAEP , ...)
Probably ALICE would want to use the new RSAES-OAEP, but does = BOB support=20 it?
If I understood you correctly, this binding between the key and = the=20 scheme IS NOT made by a X.509 certificate (except when the = retation is=20 1-1) and has to be built by other means (possibly defined by the = protocol P).=20 I'm I right?
 
I assume that the source of my initial confusion comes from the = fact=20 that, in PKCS#1, the same OID (rsaEncryption) is used to identify = both a=20 key and a encryption scheme.
 
 
Once again, I thank you for your reply
 
Best regards
 
- Pedro=20 Felix
------_=_NextPart_001_01BF66E4.98F2C2AA-- From owner-ietf-smime Mon Feb 7 06:24:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26596 for ietf-smime-bks; Mon, 7 Feb 2000 06:24:48 -0800 (PST) Received: from igas2.postoffice.co.uk (firewall-user@igas2-2.igas.postoffice.co.uk [194.152.87.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26592 for ; Mon, 7 Feb 2000 06:24:46 -0800 (PST) Received: by igas2.postoffice.co.uk; id OAA19249; Mon, 7 Feb 2000 14:27:30 GMT Received: from unknown(10.5.4.1) by igas2.postoffice.co.uk via smap (V5.0) id xma018959; Mon, 7 Feb 00 14:27:17 GMT Received: with SMTP id OAA04556 for ; Mon, 7 Feb 2000 14:27:15 GMT From: "Graham Laws" To: "'SMIME IETF'" Subject: Problem for public CAs Date: Mon, 7 Feb 2000 14:24:16 -0000 Message-ID: <035701bf7177$0461d2f0$591d050a@itmo61481> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For public CAs, particularly in Europe, the requirement to place an email address in the subjectAltname extension of each x.509 public key certificate in order to enable S/MIME is a big problem. Firstly, all such certificates must reside in a public Directory. Any determined spammer is going to be able to easily create an immense spam list from the Directory's entire certificate population, using a few LDAP calls and an ASN.1 decoder. Our customers are already nervous at the prospect of this, and for potential customers it may be a significant bar to take-up. Secondly, the European Privacy Directive looks very unfavourably upon real-world identities being in any way expressed both in the Subject and SubjectAltName attributes of the public key certificate. This would appear to rule out S/MIME for those whose names are embedded in their email addresses, e.g. graham.laws@postoffice.co.uk The issues raised by the second point are relatively easy to circumvent. Use pseudonymous names for the Subject, and insist on a pseudonymous email address if S/MIME is required. But the first point about the ease with which spam lists can be created is a real worrier. I have looked through previous threads, including the one entitled "Mail addresses in S/MIME certs", but I can't find where these specific issues have been discussed before. Comments/discussion via this forum welcome. Best Regards Graham Laws ______________________________________________ Graham Laws PKI Systems Technical Consultant Royal Mail ViaCode Phone : +44 (0)1246-293761 Block A, 1st Floor Postline : 5453-3761 St. Mary's Court Fax : +44 (0)1246-293751 St. Mary's Gate Chesterfield S41 7TD Public Key Validation String : MXZQ-7MM5-9A58 From owner-ietf-smime Mon Feb 7 09:05:40 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA00301 for ietf-smime-bks; Mon, 7 Feb 2000 09:05:40 -0800 (PST) Received: from igas2.postoffice.co.uk (firewall-user@igas2-2.igas.postoffice.co.uk [194.152.87.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00297 for ; Mon, 7 Feb 2000 09:05:39 -0800 (PST) Received: by igas2.postoffice.co.uk; id RAA18862; Mon, 7 Feb 2000 17:07:08 GMT Received: from unknown(10.5.4.1) by igas2.postoffice.co.uk via smap (V5.0) id xma018666; Mon, 7 Feb 00 17:06:56 GMT Received: with SMTP id RAA18470; Mon, 7 Feb 2000 17:06:54 GMT From: "Graham Laws" To: "'Bill Brice (listserv)'" Cc: "'SMIME IETF'" Subject: RE: Problem for public CAs Date: Mon, 7 Feb 2000 17:03:56 -0000 Message-ID: <035b01bf718d$52c5ded0$591d050a@itmo61481> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9E60D6A452AAD211904E00105A1973FD072BC9@ATDEV1> Importance: Normal Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bill, Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to encrypt a message to you, I would be able to find your public key certificate, if the CA's directory entries are not open to the public ? (to avoid cross-cert issues, lets assume we both belong to the same CA). Are you assuming that correspondents will swap key files and use some out-of-band authentication mechanism ? Or can your clients only gain access to the directory for searches, etc., by using their certificates, e.g. by LDAPv3 TLS or SASL ? The S/MIME requirement to place email address in the certificate severely weakens the PKI model with regard to privacy, and will no doubt lead to all sorts of bespoke solutions for public Directories. I suspect this will also lead to many interoperability problems later. Best Regards Graham -----Original Message----- From: Bill Brice (listserv) [mailto:list.bill.brice@AlphaTrust.com] Sent: 07 February 2000 15:54 To: 'Graham Laws' Subject: RE: Problem for public CAs Graham, As a US based public CA that incorporates EU Privacy and Data Protection directives into our PKI, we have addressed this issue as follows: 1) Our Members give their permission, as required by EU law, to incorporate common names and email addresses into their certificates. 2) Our Members pledge, as part of their Member Agreement, not to use another Members information for purposes such as spam. 3) Our directory entries are not open to the public, unless the Member has agreed to publish such information publicly. 4) Relying parties have agreed to respect the privacy rights of our Members and not to use personally identifiable information without the Member's permission. Such a solution is possible with a contractually-based public PKI such as AlphaTrust. It is more difficult to implement with an enterprise model or an open model (i.e. Verisign). But then that's why we exist - to solve the sticky issues of privacy, legality and transaction risk. Food for thought. Bill Brice, CEO http://alphatrust.com -----Original Message----- From: Graham Laws [mailto:lawsg@it.postoffice.co.uk] Sent: Monday, February 07, 2000 8:24 AM To: 'SMIME IETF' Subject: Problem for public CAs For public CAs, particularly in Europe, the requirement to place an email address in the subjectAltname extension of each x.509 public key certificate in order to enable S/MIME is a big problem. Firstly, all such certificates must reside in a public Directory. Any determined spammer is going to be able to easily create an immense spam list from the Directory's entire certificate population, using a few LDAP calls and an ASN.1 decoder. Our customers are already nervous at the prospect of this, and for potential customers it may be a significant bar to take-up. Secondly, the European Privacy Directive looks very unfavourably upon real-world identities being in any way expressed both in the Subject and SubjectAltName attributes of the public key certificate. This would appear to rule out S/MIME for those whose names are embedded in their email addresses, e.g. graham.laws@postoffice.co.uk The issues raised by the second point are relatively easy to circumvent. Use pseudonymous names for the Subject, and insist on a pseudonymous email address if S/MIME is required. But the first point about the ease with which spam lists can be created is a real worrier. I have looked through previous threads, including the one entitled "Mail addresses in S/MIME certs", but I can't find where these specific issues have been discussed before. Comments/discussion via this forum welcome. Best Regards Graham Laws ______________________________________________ Graham Laws PKI Systems Technical Consultant Royal Mail ViaCode Phone : +44 (0)1246-293761 Block A, 1st Floor Postline : 5453-3761 St. Mary's Court Fax : +44 (0)1246-293751 St. Mary's Gate Chesterfield S41 7TD Public Key Validation String : MXZQ-7MM5-9A58 From owner-ietf-smime Mon Feb 7 10:35:40 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA02369 for ietf-smime-bks; Mon, 7 Feb 2000 10:35:40 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02365 for ; Mon, 7 Feb 2000 10:35:39 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA06623 for ; Mon, 7 Feb 2000 13:38:51 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA06618 for ; Mon, 7 Feb 2000 13:38:51 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA20864 for ; Mon, 7 Feb 2000 13:38:47 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA11058 for ; Mon, 7 Feb 2000 13:36:16 -0500 (EST) Message-Id: <200002071836.NAA11058@ara.missi.ncsc.mil> Date: Mon, 7 Feb 2000 13:36:16 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Problem for public CAs To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nIijzPrls4LyDnNfOF1DyA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graham, The problem with requiring email addresses in certificates (assuming the address is examined by Mail User Agents) is much more basic: the identity certified by a CA has in principle nothing to do with where email is sent from or delivered to. Regardless of whether I want my Certified Net Nym to be "Dave Kemp" or "dpkemp@missi.ncsc.mil", I should be able to send and receive S/MIME messages using any address, including "dave@alumni.podunk.edu" and "12345@compuserve.com", without having to know in advance where I might be or who I'll be using for an ISP. The concept that Identification and Authentication should be independent of transport addressing seems not to have gained traction last time around, for some unfathomable reason. Perhaps the spam and privacy arguments will resonate more effectively with readers of this list. Good luck. Dave > From: "Graham Laws" > To: "'SMIME IETF'" > Subject: Problem for public CAs > Date: Mon, 7 Feb 2000 14:24:16 -0000 > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 > Importance: Normal > List-Archive: > List-ID: > List-Unsubscribe: > > For public CAs, particularly in Europe, the requirement to place an email > address in the subjectAltname extension of each x.509 public key certificate > in order to enable S/MIME is a big problem. > > Firstly, all such certificates must reside in a public Directory. Any > determined spammer is going to be able to easily create an immense spam list > from the Directory's entire certificate population, using a few LDAP calls > and an ASN.1 decoder. Our customers are already nervous at the prospect of > this, and for potential customers it may be a significant bar to take-up. > > Secondly, the European Privacy Directive looks very unfavourably upon > real-world identities being in any way expressed both in the Subject and > SubjectAltName attributes of the public key certificate. This would appear > to rule out S/MIME for those whose names are embedded in their email > addresses, e.g. graham.laws@postoffice.co.uk > > The issues raised by the second point are relatively easy to circumvent. Use > pseudonymous names for the Subject, and insist on a pseudonymous email > address if S/MIME is required. > > But the first point about the ease with which spam lists can be created is a > real worrier. I have looked through previous threads, including the one > entitled "Mail addresses in S/MIME certs", but I can't find where these > specific issues have been discussed before. > > Comments/discussion via this forum welcome. > > Best Regards > Graham Laws > > ______________________________________________ > Graham Laws > PKI Systems Technical Consultant > Royal Mail ViaCode Phone : +44 (0)1246-293761 > Block A, 1st Floor Postline : 5453-3761 > St. Mary's Court Fax : +44 (0)1246-293751 > St. Mary's Gate > Chesterfield > S41 7TD > > Public Key Validation String : MXZQ-7MM5-9A58 > > From owner-ietf-smime Mon Feb 7 10:30:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA02309 for ietf-smime-bks; Mon, 7 Feb 2000 10:30:07 -0800 (PST) Received: from mrelay1.swift.com (begis50.swift.com [149.134.97.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02305 for ; Mon, 7 Feb 2000 10:30:06 -0800 (PST) Received: from bemsl01.swift.com by mrelay1.swift.com (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) with ESMTP id <0FPK00M02OUQEN@mrelay1.swift.com> for ietf-smime@imc.org; Mon, 7 Feb 2000 18:32:50 +0000 (GMT) Received: from swift.com ([172.24.66.185]) by bemsl01.swift.com (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FPK00K02OUPBA@bemsl01.swift.com> for ietf-smime@imc.org; Mon, 07 Feb 2000 18:32:49 +0000 (GMT) Date: Mon, 07 Feb 2000 19:32:57 +0100 From: HORII Naoto Subject: Re: Problem for public CAs To: ietf-smime@imc.org Message-id: <389F0FD0.80831743@swift.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61C-CCK-MCD SWIFT-M32 (Macintosh; I; PPC) Content-type: text/plain; charset=iso-8859-1; x-mac-type=54455854; x-mac-creator=4D4F5353 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <035b01bf718d$52c5ded0$591d050a@itmo61481> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Item 3 would typically be implemented by restricting the type of questions a client can ask to the CA: 1) S/MIME certificates would be returned only if the subjectAltname is unambiguously specified - e.g. client: search certificate for subjectAltname=lawsg@it.postoffice.co.uk server: OK, certificate=blah client: search certificate for subjectAltname=*@it.postoffice.co.uk server: ERROR, inavlid search key For such a protection scheme to work, your directory server must obviously be able to validate/ sanitize a search key against access rules — e.g. "no wildcards allowed in search keys" — before forwarding the search to your directory's backend engine. 2) Certificate revocation status would be returned only for explicitly specified serial numbers: client: search revocationStatus for serialNumber=12:34:56:78:9a:bc:de:f0 server: OK, revocationStatus=false client: search revocationStatus for serialNumber=12:34:56:* server: ERROR, inavlid search key Note that to prevent a trivial exploration of the certificate space by a spy intent on determining the number of certificates issued by a particular CA, the certificate's serial numbers should probably be derived from a hash of the Subject's data. A 64- or 80-bit long hash would give a serial number space large enough to prevent brute- force scans of the CRL subtree, while yielding serial numbers small enough to be accepted by most X.509 implementations. Cheers, Naoto Graham Laws wrote: > Bill, > Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to > encrypt a message to you, I would be able to find your public key > certificate, if the CA's directory entries are not open to the public ? (to > avoid cross-cert issues, lets assume we both belong to the same CA). > > Are you assuming that correspondents will swap key files and use some > out-of-band authentication mechanism ? Or can your clients only gain access > to the directory for searches, etc., by using their certificates, e.g. by > LDAPv3 TLS or SASL ? > > The S/MIME requirement to place email address in the certificate severely > weakens the PKI model with regard to privacy, and will no doubt lead to all > sorts of bespoke solutions for public Directories. I suspect this will also > lead to many interoperability problems later. > > Best Regards > Graham > > -----Original Message----- > From: Bill Brice (listserv) [mailto:list.bill.brice@AlphaTrust.com] > Sent: 07 February 2000 15:54 > To: 'Graham Laws' > Subject: RE: Problem for public CAs > > Graham, > > As a US based public CA that incorporates EU Privacy and Data Protection > directives into our PKI, we have addressed this issue as follows: > > 1) Our Members give their permission, as required by EU law, to incorporate > common names and email addresses into their certificates. > 2) Our Members pledge, as part of their Member Agreement, not to use another > Members information for purposes such as spam. > 3) Our directory entries are not open to the public, unless the Member has > agreed > to publish such information publicly. > 4) Relying parties have agreed to respect the privacy rights of our Members > and > not to use personally identifiable information without the Member's > permission. > > Such a solution is possible with a contractually-based public PKI such as > AlphaTrust. It is more difficult to implement with an enterprise model > or an open model (i.e. Verisign). But then that's why we exist - to solve > the > sticky issues of privacy, legality and transaction risk. > > Food for thought. > > Bill Brice, CEO > http://alphatrust.com > > -----Original Message----- > From: Graham Laws [mailto:lawsg@it.postoffice.co.uk] > Sent: Monday, February 07, 2000 8:24 AM > To: 'SMIME IETF' > Subject: Problem for public CAs > > For public CAs, particularly in Europe, the requirement to place an email > address in the subjectAltname extension of each x.509 public key certificate > in order to enable S/MIME is a big problem. > > Firstly, all such certificates must reside in a public Directory. Any > determined spammer is going to be able to easily create an immense spam list > from the Directory's entire certificate population, using a few LDAP calls > and an ASN.1 decoder. Our customers are already nervous at the prospect of > this, and for potential customers it may be a significant bar to take-up. > > Secondly, the European Privacy Directive looks very unfavourably upon > real-world identities being in any way expressed both in the Subject and > SubjectAltName attributes of the public key certificate. This would appear > to rule out S/MIME for those whose names are embedded in their email > addresses, e.g. graham.laws@postoffice.co.uk > > The issues raised by the second point are relatively easy to circumvent. Use > pseudonymous names for the Subject, and insist on a pseudonymous email > address if S/MIME is required. > > But the first point about the ease with which spam lists can be created is a > real worrier. I have looked through previous threads, including the one > entitled "Mail addresses in S/MIME certs", but I can't find where these > specific issues have been discussed before. > > Comments/discussion via this forum welcome. > > Best Regards > Graham Laws > > ______________________________________________ > Graham Laws > PKI Systems Technical Consultant > Royal Mail ViaCode Phone : +44 (0)1246-293761 > Block A, 1st Floor Postline : 5453-3761 > St. Mary's Court Fax : +44 (0)1246-293751 > St. Mary's Gate > Chesterfield > S41 7TD > > Public Key Validation String : MXZQ-7MM5-9A58 From owner-ietf-smime Mon Feb 7 10:25:23 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02183 for ietf-smime-bks; Mon, 7 Feb 2000 10:25:23 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02179 for ; Mon, 7 Feb 2000 10:25:22 -0800 (PST) Message-Id: <4.2.1.20000207102643.00d0fef0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 07 Feb 2000 10:28:31 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Problem for public CAs In-Reply-To: <035701bf7177$0461d2f0$591d050a@itmo61481> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hmmm. Either you identify the public key in a certificate by an appropriate identifier (and "email address" is appropriate for S/MIME), or you ignore the identification in the certificate. Are you proposing an alternative solution for S/MIME certificate usage? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Mon Feb 7 11:37:44 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03664 for ietf-smime-bks; Mon, 7 Feb 2000 11:37:44 -0800 (PST) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03660 for ; Mon, 7 Feb 2000 11:37:43 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Feb 2000 14:39:58 -0500 Message-ID: From: Brad Smith To: ietf-smime@imc.org Subject: RE: Problem for public CAs Date: Mon, 7 Feb 2000 14:39:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Unless I'm misunderstanding what you're saying, recall that 'subjectAltName' is allowed to have multiple values. So, for example, your own certificate can have all three E-mail addresses within. The advantage is that somebody doing a search on any of your known E-mail addresses will always return the same certificate. The downside (or, certainly, *a* downside) is that if somebody knows, for example, your Compuserve address, he can do a directory search for that, get your certificate, and from that learn all your other E-mail addresses. On the other hand, if you send a signed message, presumably your digital signature would contain all that information anyway. Alas, I'm unable to suggest any solutions. If it were a major issue to me personally, I'd just not allow my certificate to be published in any public CAs. But that's probably not the answer you're looking for. :-) Brad. -- Brad P. Smith [Development Lead - Entrust/Express] Entrust Technologies Inc. 750 Heron Road, Suite E800 Ottawa, Ontario, K1V 1A7, Canada mailto:brad.smith@entrust.com http://www.entrust.com -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Monday, February 7, 2000 13:36 To: ietf-smime@imc.org Subject: Re: Problem for public CAs Graham, The problem with requiring email addresses in certificates (assuming the address is examined by Mail User Agents) is much more basic: the identity certified by a CA has in principle nothing to do with where email is sent from or delivered to. Regardless of whether I want my Certified Net Nym to be "Dave Kemp" or "dpkemp@missi.ncsc.mil", I should be able to send and receive S/MIME messages using any address, including "dave@alumni.podunk.edu" and "12345@compuserve.com", without having to know in advance where I might be or who I'll be using for an ISP. The concept that Identification and Authentication should be independent of transport addressing seems not to have gained traction last time around, for some unfathomable reason. Perhaps the spam and privacy arguments will resonate more effectively with readers of this list. Good luck. Dave > From: "Graham Laws" > To: "'SMIME IETF'" > Subject: Problem for public CAs > Date: Mon, 7 Feb 2000 14:24:16 -0000 > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 > Importance: Normal > List-Archive: > List-ID: > List-Unsubscribe: > > For public CAs, particularly in Europe, the requirement to place an email > address in the subjectAltname extension of each x.509 public key certificate > in order to enable S/MIME is a big problem. > > Firstly, all such certificates must reside in a public Directory. Any > determined spammer is going to be able to easily create an immense spam list > from the Directory's entire certificate population, using a few LDAP calls > and an ASN.1 decoder. Our customers are already nervous at the prospect of > this, and for potential customers it may be a significant bar to take-up. > > Secondly, the European Privacy Directive looks very unfavourably upon > real-world identities being in any way expressed both in the Subject and > SubjectAltName attributes of the public key certificate. This would appear > to rule out S/MIME for those whose names are embedded in their email > addresses, e.g. graham.laws@postoffice.co.uk > > The issues raised by the second point are relatively easy to circumvent. Use > pseudonymous names for the Subject, and insist on a pseudonymous email > address if S/MIME is required. > > But the first point about the ease with which spam lists can be created is a > real worrier. I have looked through previous threads, including the one > entitled "Mail addresses in S/MIME certs", but I can't find where these > specific issues have been discussed before. > > Comments/discussion via this forum welcome. > > Best Regards > Graham Laws > > ______________________________________________ > Graham Laws > PKI Systems Technical Consultant > Royal Mail ViaCode Phone : +44 (0)1246-293761 > Block A, 1st Floor Postline : 5453-3761 > St. Mary's Court Fax : +44 (0)1246-293751 > St. Mary's Gate > Chesterfield > S41 7TD > > Public Key Validation String : MXZQ-7MM5-9A58 > > From owner-ietf-smime Mon Feb 7 12:40:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05128 for ietf-smime-bks; Mon, 7 Feb 2000 12:40:03 -0800 (PST) Received: from tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05124 for ; Mon, 7 Feb 2000 12:40:02 -0800 (PST) Received: from zanyclown.tycho.ncsc.mil (zanyclown [144.51.3.100]) by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id PAA00410; Mon, 7 Feb 2000 15:42:06 -0500 (EST) Received: by zanyclown.tycho.ncsc.mil with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 15:41:45 -0500 Message-ID: <098E1379385CD311A189000092922B5811A7C2@zanyclown.tycho.ncsc.mil> From: Alfred Arsenault To: "'HORII Naoto'" , ietf-smime@imc.org Subject: RE: Problem for public CAs Date: Mon, 7 Feb 2000 15:41:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----Original Message----- From: HORII Naoto [mailto:Naoto.Horii@swift.com] Sent: Monday, February 07, 2000 1:33 PM To: ietf-smime@imc.org Subject: Re: Problem for public CAs Item 3 would typically be implemented by restricting the type of questions a client can ask to the CA: 1) S/MIME certificates would be returned only if the subjectAltname is unambiguously specified - e.g. client: search certificate for subjectAltname=lawsg@it.postoffice.co.uk server: OK, certificate=blah client: search certificate for subjectAltname=*@it.postoffice.co.uk server: ERROR, inavlid search key For such a protection scheme to work, your directory server must obviously be able to validate/ sanitize a search key against access rules - e.g. "no wildcards allowed in search keys" - before forwarding the search to your directory's backend engine. AWA: Of course, this doesn't work if you allow me an unlimited number of queries to your directory. I'll just start with some of the more "obvious" possibilities and work my way out; e.g., search for: certificate for smith@company.com certificate for jsmith@company.com certificate for smithj@company.com ... It's not real efficient, but hey, that's what computer programs are for. :-) Sooner or later, I'll get a reasonable number of certs, and away I go. I'll chew up a lot of network bandwidth and leave footprints all over your directory, but if you let me search like this, it's worth it - if there's money to be made in spamming, I don't care what it costs you for me to get the addresses. :-) Al Arsenault -- insert usual disclaimer about this being my opinion, and not reflecting the opinion of my employer or of any other organization with which I have a relationship -- insert second disclaimer: no, I don't spam, I don't like spam, I don't harvest names to help somebody else spam;... From owner-ietf-smime Mon Feb 7 12:32:51 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA05010 for ietf-smime-bks; Mon, 7 Feb 2000 12:32:51 -0800 (PST) Received: from tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05006 for ; Mon, 7 Feb 2000 12:32:50 -0800 (PST) Received: from zanyclown.tycho.ncsc.mil (zanyclown [144.51.3.100]) by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id PAA00319 for ; Mon, 7 Feb 2000 15:35:06 -0500 (EST) Received: by zanyclown.tycho.ncsc.mil with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 15:34:45 -0500 Message-ID: <098E1379385CD311A189000092922B5811A7C1@zanyclown.tycho.ncsc.mil> From: Alfred Arsenault To: ietf-smime@imc.org Subject: RE: Problem for public CAs Date: Mon, 7 Feb 2000 15:34:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, I don't know how AlphaTrust does this, but one system I've been involved with in the past works as follows: - the directory mandates "strong authentication"; i.e., you have to authenticate yourself cryptographically as part of binding to the directory; - the directory enforces the policy that only people who have certificates issued by an approved CA can query the directory. That is, when you ask the directory for a certificate for user "Paul Hoffman", it verifies via the strong authentication that: - you possess the private key associated with a certificate - that certificate was issued by an approved CA. If you pass this check, the directory will search for the cert you want and return it if it can find it. - requests from other than approved users are rejected. If you aren't already in my community, you don't get information from my directory. Enforcement is via authentication to the directory; no matter who you claim to be, if you can't authenticate using a cert from an approved CA, it's the bit bucket for ya. Then, the only people who can violate the policy on combing the directory for email addresses to later be used for spam are your own users, and you have their pledge - I hope backed up with the threat of legal action - that they won't do so. Bill, is that roughly how your system works? Al Arsenault -- As usual, this posting reflects my own opinions only, and does not represent the opinions or policies of my employer or any other organization with which I may have a relationship. Graham Laws wrote: > Bill, > Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to > encrypt a message to you, I would be able to find your public key > certificate, if the CA's directory entries are not open to the public ? (to > avoid cross-cert issues, lets assume we both belong to the same CA). > > Are you assuming that correspondents will swap key files and use some > out-of-band authentication mechanism ? Or can your clients only gain access > to the directory for searches, etc., by using their certificates, e.g. by > LDAPv3 TLS or SASL ? > > The S/MIME requirement to place email address in the certificate severely > weakens the PKI model with regard to privacy, and will no doubt lead to all > sorts of bespoke solutions for public Directories. I suspect this will also > lead to many interoperability problems later. > > Best Regards > Graham > > -----Original Message----- > From: Bill Brice (listserv) [mailto:list.bill.brice@AlphaTrust.com] > Sent: 07 February 2000 15:54 > To: 'Graham Laws' > Subject: RE: Problem for public CAs > > Graham, > > As a US based public CA that incorporates EU Privacy and Data Protection > directives into our PKI, we have addressed this issue as follows: > > 1) Our Members give their permission, as required by EU law, to incorporate > common names and email addresses into their certificates. > 2) Our Members pledge, as part of their Member Agreement, not to use another > Members information for purposes such as spam. > 3) Our directory entries are not open to the public, unless the Member has > agreed > to publish such information publicly. > 4) Relying parties have agreed to respect the privacy rights of our Members > and > not to use personally identifiable information without the Member's > permission. > > Such a solution is possible with a contractually-based public PKI such as > AlphaTrust. It is more difficult to implement with an enterprise model > or an open model (i.e. Verisign). But then that's why we exist - to solve > the > sticky issues of privacy, legality and transaction risk. > > Food for thought. > > Bill Brice, CEO > http://alphatrust.com > > -----Original Message----- > From: Graham Laws [mailto:lawsg@it.postoffice.co.uk] > Sent: Monday, February 07, 2000 8:24 AM > To: 'SMIME IETF' > Subject: Problem for public CAs > > For public CAs, particularly in Europe, the requirement to place an email > address in the subjectAltname extension of each x.509 public key certificate > in order to enable S/MIME is a big problem. > > Firstly, all such certificates must reside in a public Directory. Any > determined spammer is going to be able to easily create an immense spam list > from the Directory's entire certificate population, using a few LDAP calls > and an ASN.1 decoder. Our customers are already nervous at the prospect of > this, and for potential customers it may be a significant bar to take-up. > > Secondly, the European Privacy Directive looks very unfavourably upon > real-world identities being in any way expressed both in the Subject and > SubjectAltName attributes of the public key certificate. This would appear > to rule out S/MIME for those whose names are embedded in their email > addresses, e.g. graham.laws@postoffice.co.uk > > The issues raised by the second point are relatively easy to circumvent. Use > pseudonymous names for the Subject, and insist on a pseudonymous email > address if S/MIME is required. > > But the first point about the ease with which spam lists can be created is a > real worrier. I have looked through previous threads, including the one > entitled "Mail addresses in S/MIME certs", but I can't find where these > specific issues have been discussed before. > > Comments/discussion via this forum welcome. > > Best Regards > Graham Laws > > ______________________________________________ > Graham Laws > PKI Systems Technical Consultant > Royal Mail ViaCode Phone : +44 (0)1246-293761 > Block A, 1st Floor Postline : 5453-3761 > St. Mary's Court Fax : +44 (0)1246-293751 > St. Mary's Gate > Chesterfield > S41 7TD > > Public Key Validation String : MXZQ-7MM5-9A58 From owner-ietf-smime Tue Feb 8 01:41:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA00901 for ietf-smime-bks; Tue, 8 Feb 2000 01:41:45 -0800 (PST) Received: from mrelay1.swift.com (begis50.swift.com [149.134.97.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA00896 for ; Tue, 8 Feb 2000 01:41:43 -0800 (PST) Received: from bemsl01.swift.com by mrelay1.swift.com (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) with ESMTP id <0FPL00H02UYVHR@mrelay1.swift.com> for ietf-smime@imc.org; Tue, 8 Feb 2000 09:42:31 +0000 (GMT) Received: from swift.com ([172.24.66.185]) by bemsl01.swift.com (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FPL00I02UYUJD@bemsl01.swift.com> for ietf-smime@imc.org; Tue, 08 Feb 2000 09:42:30 +0000 (GMT) Date: Tue, 08 Feb 2000 10:42:33 +0100 From: HORII Naoto Subject: Re: Problem for public CAs To: ietf-smime@imc.org Message-id: <389FE506.DE19D888@swift.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61C-CCK-MCD SWIFT-M32 (Macintosh; I; PPC) Content-type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-transfer-encoding: 7bit X-Accept-Language: en References: <098E1379385CD311A189000092922B5811A7C2@zanyclown.tycho.ncsc.mil> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alfred Arsenault wrote: > -----Original Message----- > From: HORII Naoto [mailto:Naoto.Horii@swift.com] > Sent: Monday, February 07, 2000 1:33 PM > To: ietf-smime@imc.org > Subject: Re: Problem for public CAs > > Item 3 would typically be implemented by restricting the type of questions a > client can ask to the CA: > > 1) S/MIME certificates would be returned only if the subjectAltname is > unambiguously specified - e.g. > > client: search certificate for subjectAltname=lawsg@it.postoffice.co.uk > server: OK, certificate=blah > > client: search certificate for subjectAltname=*@it.postoffice.co.uk > server: ERROR, inavlid search key > > For such a protection scheme to work, your directory server must obviously > be able to validate/ > sanitize a search key against access rules - e.g. "no wildcards allowed in > search keys" - before > forwarding the search to your directory's backend engine. > > > > AWA: Of course, this doesn't work if you allow me an unlimited number of > queries to your directory. I'll just start with some of the more "obvious" > possibilities and work my way out; e.g., > > search for: certificate for smith@company.com > certificate for jsmith@company.com > certificate for smithj@company.com > ... > > It's not real efficient, but hey, that's what computer programs are for. :-) > Sooner or later, I'll get a reasonable number of certs, and away I go. I'll > chew up a lot of network bandwidth and leave footprints all over your > directory, but if you let me search like this, it's worth it - if there's > money to be made in spamming, I don't care what it costs you for me to get > the addresses. :-) My assumption, of course, is that it would be less expensive for a spammer to just send his/her mail via an open relay mail gateway to smith@company.com, smith@company.com, smithj@company.com -- even if most of these addresses will be invalid -- than to look up digital certificates for these addresses before sending the mails. It usually doesn't make sense for a spammer to use the target's certificate to encrypt the spam: doing so makes evey message unique and the spammer then loses the leverage of being able to dispatch a mountain of e-mail by forwarding just a single copy of the mail to an open relay SMTP server together with a space-efficient recipient address list. For e-mail, I think the privacy concerns of having your e-mail address -- once it's known -- easily mappable to a PKI certificate via a publicly accesible directory are outweighed by the benefit of allowing people to authemticate your mails or send you encrypted data. E-mail addresses are just one of the numerous coordinate points -- which include e.g. mobile and fax phone numbers, e-mail addresses, URLs, X.500 DNs... -- people can use to sort of locate you in an abstract digital space. IMHO these coordinate's connection with the "real" physical world in which you live can be made quite tenuous if you are careful enough... Are we straying more and more off-topic for this forum or what ;-) Cheers, Naoto From owner-ietf-smime Tue Feb 8 07:38:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10092 for ietf-smime-bks; Tue, 8 Feb 2000 07:38:32 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10088 for ; Tue, 8 Feb 2000 07:38:31 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA12861 for ; Tue, 8 Feb 2000 07:37:09 -0800 (PST) Message-Id: <4.2.0.58.20000208102841.00a0ccc0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 10:32:29 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: 47th IETF: S/MIME WG Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Working Group: The S/MIME WG meeting is currently scheduled for WEDNESDAY, March 29, 2000 from 1530 to 1730. As usual, scheduling is tentative and subject to change. So, I am now putting together the agenda for the meeting. Please send me requests for time slots. Russ From owner-ietf-smime Wed Feb 9 06:36:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA27193 for ietf-smime-bks; Wed, 9 Feb 2000 06:36:30 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27189 for ; Wed, 9 Feb 2000 06:36:28 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA03812 for ; Wed, 9 Feb 2000 09:39:54 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA03807 for ; Wed, 9 Feb 2000 09:39:53 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA15114 for ; Wed, 9 Feb 2000 09:39:49 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA12067 for ; Wed, 9 Feb 2000 09:37:13 -0500 (EST) Message-Id: <200002091437.JAA12067@ara.missi.ncsc.mil> Date: Wed, 9 Feb 2000 09:37:13 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Problem for public CAs To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VyV4rrR6ewKjW3JlbybK+w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brad, The problem is that I may not *want* to have two or more E-mail addresses within the subjectAltName extension of my certificates. Many organizations choose to present organizational email addresses for all employees, regardless of how email is delivered within the organization. My external address is "dpkemp@missi.ncsc.mil'. Internally, email addresses include hostnames - my internal address could be (but isn't :-) something like 'dpkemp@popcorn.missi.ncsc.mil'. Our network administrators have configured Microsoft Outlook so that users use internal addresses for their internal workstations. As far as I know, that is standard practice. If S/MIME requires transport addresses to be present in certificates, that means my certificate MUST contain both 'dpkemp@missi.ncsc.mil' and 'dpkemp@popcorn.missi.ncsc.mil' if I want to be able to both send and receive S/MIME messages. This is a defect. I claim that the defect is with the S/MIME spec, not with the mail transport infrastructure. Dave > From: Brad Smith > To: ietf-smime@imc.org > Subject: RE: Problem for public CAs > Date: Mon, 7 Feb 2000 14:39:57 -0500 > > Unless I'm misunderstanding what you're saying, recall that 'subjectAltName' > is allowed to have multiple values. So, for example, your own certificate > can have all three E-mail addresses within. > > The advantage is that somebody doing a search on any of your known E-mail > addresses will always return the same certificate. > > The downside (or, certainly, *a* downside) is that if somebody knows, for > example, your Compuserve address, he can do a directory search for that, get > your certificate, and from that learn all your other E-mail addresses. > > On the other hand, if you send a signed message, presumably your digital > signature would contain all that information anyway. > > Alas, I'm unable to suggest any solutions. If it were a major issue to me > personally, I'd just not allow my certificate to be published in any public > CAs. But that's probably not the answer you're looking for. :-) > > Brad. > -- > Brad P. Smith [Development Lead - Entrust/Express] > Entrust Technologies Inc. > 750 Heron Road, Suite E800 > Ottawa, Ontario, K1V 1A7, Canada > mailto:brad.smith@entrust.com http://www.entrust.com From owner-ietf-smime Wed Feb 9 08:26:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29088 for ietf-smime-bks; Wed, 9 Feb 2000 08:26:49 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29084 for ; Wed, 9 Feb 2000 08:26:48 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA00513; Wed, 9 Feb 2000 08:25:28 -0800 (PST) Message-Id: <4.2.0.58.20000209112713.00a10400@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 09 Feb 2000 11:27:35 -0500 To: "Graham Laws" From: Russ Housley Subject: Re: Problem for public CAs Cc: "'SMIME IETF'" In-Reply-To: <035701bf7177$0461d2f0$591d050a@itmo61481> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graham: Certificates usually contain a subject name and a public key. However, this information is not adequate for a mail user agent to determine which certificate goes with a particular e-mail address. That is why the S/MIME RFCs require the inclusion of the e-mail address in the subjectAltName. Several people have tried to build S/MIME capabilities that support certificates without e-mail address in the subjectAltName. The results are security vulnerabilities! The address book must be used to associate the certificate and the e-mail address. Users are not very good at associating the correct certificate with the correct address book entry (that is, the correct e-mail address). This mismatch has impacts on both authentication and confidentiality. Russ At 02:24 PM 02/07/2000 +0000, Graham Laws wrote: >For public CAs, particularly in Europe, the requirement to place an email >address in the subjectAltname extension of each x.509 public key certificate >in order to enable S/MIME is a big problem. > >Firstly, all such certificates must reside in a public Directory. Any >determined spammer is going to be able to easily create an immense spam list >from the Directory's entire certificate population, using a few LDAP calls >and an ASN.1 decoder. Our customers are already nervous at the prospect of >this, and for potential customers it may be a significant bar to take-up. > >Secondly, the European Privacy Directive looks very unfavourably upon >real-world identities being in any way expressed both in the Subject and >SubjectAltName attributes of the public key certificate. This would appear >to rule out S/MIME for those whose names are embedded in their email >addresses, e.g. graham.laws@postoffice.co.uk > >The issues raised by the second point are relatively easy to circumvent. Use >pseudonymous names for the Subject, and insist on a pseudonymous email >address if S/MIME is required. > >But the first point about the ease with which spam lists can be created is a >real worrier. I have looked through previous threads, including the one >entitled "Mail addresses in S/MIME certs", but I can't find where these >specific issues have been discussed before. > >Comments/discussion via this forum welcome. > >Best Regards >Graham Laws > >______________________________________________ >Graham Laws >PKI Systems Technical Consultant >Royal Mail ViaCode Phone : +44 (0)1246-293761 >Block A, 1st Floor Postline : 5453-3761 >St. Mary's Court Fax : +44 (0)1246-293751 >St. Mary's Gate >Chesterfield >S41 7TD > >Public Key Validation String : MXZQ-7MM5-9A58 From owner-ietf-smime Wed Feb 9 08:41:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29398 for ietf-smime-bks; Wed, 9 Feb 2000 08:41:11 -0800 (PST) Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29394 for ; Wed, 9 Feb 2000 08:41:09 -0800 (PST) Received: (qmail 27536 invoked from network); 9 Feb 2000 16:43:58 -0000 Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 9 Feb 2000 16:43:58 -0000 Received: (qmail 4024 invoked from network); 9 Feb 2000 16:43:58 -0000 Received: from tdean.eris.dera.gov.uk (HELO tdean) (128.98.10.5) by mail-relay.eris.dera.gov.uk with SMTP; 9 Feb 2000 16:43:58 -0000 Received: by localhost with Microsoft MAPI; Wed, 9 Feb 2000 16:44:37 -0000 Message-ID: <01BF731C.F3E45810.t.dean@eris.dera.gov.uk> From: Tim Dean Reply-To: "t.dean@eris.dera.gov.uk" To: "'David P. Kemp'" Cc: "ietf-smime@imc.org" Subject: RE: Problem for public CAs Date: Wed, 9 Feb 2000 16:44:35 -0000 Organization: DERA X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave, What you describe is also the practice in our organisation: a fairly simple addressing structure is presented to the "external world" and a much richer structure is used internally . I also agree with you that having multiple e-mail addresses in certificates is a bad idea for several reasons: it gives away organisational structure that in some cases is sensitive. Furthermore, it may give away other things about the organisation, such as which employees are involved in mobile working, for example. In order to address this kind of requirement in S/MIME, this is precisely the motivation for the "domain Signature" in the domain security services draft. We have there a name mapping convention (section 3.1.1) that says that the bit on the right-hand side of the '@' symbol in the certificate of the domain signer must be the same as, or an ascendant of that in the originator's address. ( thus for my e-mail address, t.dean@eris.dera.gov.uk, the domain signature could contain domain-signing-authority@dera.gov.uk). At the last meeting, I believe there was a question raised as to whether allowing a subset of the originators address in the domain signature is such a good idea. Some people felt that forcing them to be identical would be better - ie for t.dean@eris.dera.gov.uk the domain signer must be domain-signing-authority@eris.dera.gov.uk, nothing more, nothing less. (The arguments were not discussed in detail.) We can't make up our minds on this one: we are probably leaning in favour of allowing the greater flexibility, and therefore relying on the CA naming policy to prevent certificates with non-sensible names (e.g. tim@uk!). However, if you or others have views on this, they would be most appreciated. We very much hope to nail down this issue soon, so we can move the Draft towards last call. Regards, Tim -----Original Message----- From: David P. Kemp [SMTP:dpkemp@missi.ncsc.mil] Sent: 09 February 2000 14:37 To: ietf-smime@imc.org Subject: RE: Problem for public CAs Brad, The problem is that I may not *want* to have two or more E-mail addresses within the subjectAltName extension of my certificates. Many organizations choose to present organizational email addresses for all employees, regardless of how email is delivered within the organization. My external address is "dpkemp@missi.ncsc.mil'. Internally, email addresses include hostnames - my internal address could be (but isn't :-) something like 'dpkemp@popcorn.missi.ncsc.mil'. Our network administrators have configured Microsoft Outlook so that users use internal addresses for their internal workstations. As far as I know, that is standard practice. If S/MIME requires transport addresses to be present in certificates, that means my certificate MUST contain both 'dpkemp@missi.ncsc.mil' and 'dpkemp@popcorn.missi.ncsc.mil' if I want to be able to both send and receive S/MIME messages. This is a defect. I claim that the defect is with the S/MIME spec, not with the mail transport infrastructure. Dave > From: Brad Smith > To: ietf-smime@imc.org > Subject: RE: Problem for public CAs > Date: Mon, 7 Feb 2000 14:39:57 -0500 > > Unless I'm misunderstanding what you're saying, recall that 'subjectAltName' > is allowed to have multiple values. So, for example, your own certificate > can have all three E-mail addresses within. > > The advantage is that somebody doing a search on any of your known E-mail > addresses will always return the same certificate. > > The downside (or, certainly, *a* downside) is that if somebody knows, for > example, your Compuserve address, he can do a directory search for that, get > your certificate, and from that learn all your other E-mail addresses. > > On the other hand, if you send a signed message, presumably your digital > signature would contain all that information anyway. > > Alas, I'm unable to suggest any solutions. If it were a major issue to me > personally, I'd just not allow my certificate to be published in any public > CAs. But that's probably not the answer you're looking for. :-) > > Brad. > -- > Brad P. Smith [Development Lead - Entrust/Express] > Entrust Technologies Inc. > 750 Heron Road, Suite E800 > Ottawa, Ontario, K1V 1A7, Canada > mailto:brad.smith@entrust.com http://www.entrust.com From owner-ietf-smime Wed Feb 9 09:13:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00207 for ietf-smime-bks; Wed, 9 Feb 2000 09:13:38 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00201 for ; Wed, 9 Feb 2000 09:13:37 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA24841 for ; Wed, 9 Feb 2000 12:17:01 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA24836 for ; Wed, 9 Feb 2000 12:17:00 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA17335 for ; Wed, 9 Feb 2000 12:16:56 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id MAA12123 for ; Wed, 9 Feb 2000 12:14:19 -0500 (EST) Message-Id: <200002091714.MAA12123@ara.missi.ncsc.mil> Date: Wed, 9 Feb 2000 12:14:19 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Problem for public CAs To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DwiWZh3kX07nptstkA9NSw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Please describe a security vulnerability that is caused by lack of email address in subjectAltName. * In the case of authentication: I sign my own messages with (one of) my own certs. The subject name of my cert is displayed to the recipient when the message signature is validated. What vulnerability is introduced if a message signed by "C=US ... CN=David Kemp" comes from any email address, or mail list address, in the world? The "from" and "reply-to" fields are both irrelevant to the authentication. * In the case of confidentiality: I want to send a message to "C=CA ... CN=Joe Smith". I look up Joe's email address in my address book, which might be correct or incorrect. If Joe receives the message using whatever email address I have for him, he can read the message. If my address book is incorrect and Fred receives the message, he can't read it because he doesn't have Joe's private key. It seems to me that if there are security vulnerabilities, they are the result of a flawed HMI, not a flawed certificate profile. If the HMI does not associate the subjectName with the message to which it is cryptographically bound, you will have vulnerabilities. Dave > Date: Wed, 09 Feb 2000 11:27:35 -0500 > To: "Graham Laws" > From: Russ Housley > Subject: Re: Problem for public CAs > Cc: "'SMIME IETF'" > Graham: > > Certificates usually contain a subject name and a public key. However, > this information is not adequate for a mail user agent to determine which > certificate goes with a particular e-mail address. That is why the S/MIME > RFCs require the inclusion of the e-mail address in the subjectAltName. > > Several people have tried to build S/MIME capabilities that support > certificates without e-mail address in the subjectAltName. The results are > security vulnerabilities! The address book must be used to associate the > certificate and the e-mail address. Users are not very good at associating > the correct certificate with the correct address book entry (that is, the > correct e-mail address). This mismatch has impacts on both authentication > and confidentiality. > > Russ From owner-ietf-smime Wed Feb 9 11:28:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02640 for ietf-smime-bks; Wed, 9 Feb 2000 11:28:52 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02632 for ; Wed, 9 Feb 2000 11:28:49 -0800 (PST) From: John_Payne@motorcity2.lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA25873 for ; Wed, 9 Feb 2000 14:46:38 -0500 (EST) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet2.lotus.com (8.9.3/8.9.3) with SMTP id OAA15607 for ; Wed, 9 Feb 2000 14:30:57 -0500 (EST) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256880.006B20B0 ; Wed, 9 Feb 2000 14:30:07 -0500 X-Lotus-FromDomain: NOTES@ALPHABETA To: ietf-smime@imc.org Message-ID: <85256880.006B2086.00@motorcity2.lotus.com> Date: Wed, 9 Feb 2000 15:34:39 -0500 Subject: Re: Problem for public CAs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, but just what is it that is cryptographically bound? In many cases, requests for a certificate are submitted via mail and the certificate is returned by mail (or at least the notification that the certificate is ready). We are starting to cross the line of the CA's policy. It seems to me that the approach to both Signature Verification and the faith put in non-disclosure have been far too simplified. In cases where the CA Policy is based solely on the e-mail address then it makes sense that ALL that is cryptographicalyly bound IS the e-mail address and this have no relevance at all to the source's claimed identity. If you want more than that then you should not trust such a CA, and the binding should be to some other credential which must somehow be incorporated into the message. >Russ, > >Please describe a security vulnerability that is caused by lack of >email address in subjectAltName. > >* In the case of authentication: >I sign my own messages with (one of) my own certs. The subject name of >my cert is displayed to the recipient when the message signature is >validated. What vulnerability is introduced if a message signed by >"C=US ... CN=David Kemp" comes from any email address, or mail list >address, in the world? The "from" and "reply-to" fields are both >irrelevant to the authentication. > >* In the case of confidentiality: >I want to send a message to "C=CA ... CN=Joe Smith". I look up Joe's >email address in my address book, which might be correct or incorrect. >If Joe receives the message using whatever email address I have for him, >he can read the message. If my address book is incorrect and Fred >receives the message, he can't read it because he doesn't have Joe's >private key. > >It seems to me that if there are security vulnerabilities, they are >the result of a flawed HMI, not a flawed certificate profile. If >the HMI does not associate the subjectName with the message to which >it is cryptographically bound, you will have vulnerabilities. > >Dave From owner-ietf-smime Wed Feb 9 13:46:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05177 for ietf-smime-bks; Wed, 9 Feb 2000 13:46:58 -0800 (PST) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05172 for ; Wed, 9 Feb 2000 13:46:54 -0800 (PST) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.9.3/8.9.3) with ESMTP id HAA00908; Thu, 10 Feb 2000 07:49:40 +1000 (EST) Message-Id: <200002092149.HAA00908@typhoon.dstc.qut.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "David P. Kemp" Cc: ietf-smime@imc.org Subject: Re: Problem for public CAs In-reply-to: Your message of "Wed, 09 Feb 2000 12:14:19 EST." <200002091714.MAA12123@ara.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Feb 2000 07:49:40 +1000 From: Dean Povey Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Russ, > >Please describe a security vulnerability that is caused by lack of >email address in subjectAltName. > >* In the case of authentication: >I sign my own messages with (one of) my own certs. The subject name of >my cert is displayed to the recipient when the message signature is >validated. What vulnerability is introduced if a message signed by >"C=US ... CN=David Kemp" comes from any email address, or mail list >address, in the world? The "from" and "reply-to" fields are both >irrelevant to the authentication. > >* In the case of confidentiality: >I want to send a message to "C=CA ... CN=Joe Smith". I look up Joe's >email address in my address book, which might be correct or incorrect. >If Joe receives the message using whatever email address I have for him, >he can read the message. If my address book is incorrect and Fred >receives the message, he can't read it because he doesn't have Joe's >private key. > Sure, this is fine if you know the person you are communicating with by email personally, and aware of all the context that is implicit in their email address and hence the right DN to pick. But what if I get the following: From: js@acme.com Subject: Request for Proposal for the provision of Consulting Services To: Security Consultants Mailing List Which of the following DN's is the correct one? C=AU, OU=Accounting, O=ACME, CN=John Smith C=AU, OU=Accounting, O=ACME, CN=Jane Siegfried C=AU, OU=Hacking, O=ACME, CN=John Smith C=US, OU=Accounting, O=ACME, CN=John Smith C=ZA, OU=Consulting, O=ACME Rival Security Consultants, CN=John Smith etc. etc. So all I have to do to forge an email that looks like it comes from a valid address is to come up with DN that looks plausible. The problem with relying on global names in general is that they don't include the associated context (often referred to by the SPKI community as the "which John Smith" problem). The reason you make them stick the email address in the cert is that this is absolutely bound to the message, wheras there is no guarantee that the DN and email map to the same entity. The cert can then make the mapping between email and DN explicit hence linking the DN to the message. Sure, the person who "owns" js@acme.com can later point out that the DN used in the certificate is not them, but it is a bit late after you have just replied to them and sent a message encrypted with the hacker's public key. The answer to the privacy problem for public certificates is simple. Don't publish your certificate if you are worried about it. Go to a CA whose certificate policy is not to publish in a public directory and give out your certificate to those you trust. -- Dean Povey, | e-m: povey@dstc.edu.au | JCSI: Java Crypto Toolkit Research Scientist | ph: +61 7 3864 5120 | security.dstc.edu.au/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - C++ PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ From owner-ietf-smime Wed Feb 9 16:01:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA07076 for ietf-smime-bks; Wed, 9 Feb 2000 16:01:49 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07072 for ; Wed, 9 Feb 2000 16:01:48 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id TAA06259 for ; Wed, 9 Feb 2000 19:05:14 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id TAA06255 for ; Wed, 9 Feb 2000 19:05:14 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id TAA23681 for ; Wed, 9 Feb 2000 19:05:09 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id TAA12163 for ; Wed, 9 Feb 2000 19:02:34 -0500 (EST) Message-Id: <200002100002.TAA12163@ara.missi.ncsc.mil> Date: Wed, 9 Feb 2000 19:02:34 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Problem for public CAs To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j/VaByAlx1qi3fsAN68bag== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > To: "David P. Kemp" > Cc: ietf-smime@imc.org > Subject: Re: Problem for public CAs > Date: Thu, 10 Feb 2000 07:49:40 +1000 > From: Dean Povey > > Sure, this is fine if you know the person you are communicating with by > email personally, and aware of all the context that is implicit in their > email address and hence the right DN to pick. But what if I get the > following: > > From: js@acme.com > Subject: Request for Proposal for the provision of Consulting Services > To: Security Consultants Mailing List > > Which of the following DN's is the correct one? > > C=AU, OU=Accounting, O=ACME, CN=John Smith > C=AU, OU=Accounting, O=ACME, CN=Jane Siegfried > C=AU, OU=Hacking, O=ACME, CN=John Smith > C=US, OU=Accounting, O=ACME, CN=John Smith > C=ZA, OU=Consulting, O=ACME Rival Security Consultants, CN=John Smith > > etc. etc. If the message you received from "js" is an S/MIME message, only one cert will validate the signature or decrypt the body, so you know which DN is correct. If the message from "js" is not S/MIME, you don't need a cert at all. > So all I have to do to forge an email that looks like it comes from a > valid address is to come up with DN that looks plausible. The problem > with relying on global names in general is that they don't include the > associated context (often referred to by the SPKI community as the "which > John Smith" problem). The reason you make them stick the email address in > the cert is that this is absolutely bound to the message, wheras there is no > guarantee that the DN and email map to the same entity. The cert can then > make the mapping between email and DN explicit hence linking the DN to the > message. > > Sure, the person who "owns" js@acme.com can later point out that the DN > used in the certificate is not them, but it is a bit late after you have > just replied to them and sent a message encrypted with the hacker's public > key. How does the person who owns js@acme.com get involved in the first place? If a hacker sends you an S/MIME message with the hacker's cert, you can reply to it "securely" (with a message the hacker can decode). What motivation is there for the hacker to cause the reply to be delivered to "js@acme.com" where, presumably, the hacker can't get it and the "real" js can't decrypt it? You bootstrap an electronic identity by what you say. If I send out signed S/MIME messages all of which can be verified by the same cert, it doesn't matter whether some of them come from a home rfc822 address and others come from a work rfc822 address. If I want them linked to the same persona I'll use the same cert. It also doesn't matter whether the DN is a name with physical significance or a 'nym. All that matters is that the messages come from the possessor of one private key. If you have a collection of S/MIME messages with two different certs, with similar or even identical DNs: C=AU, OU=Accounting, O=ACME, CN=John Smith (issuer A, public key X) C=AU, OU=Accounting, O=ACME, CN=John Smith (issuer B, public key Y) you will have enough context to label one address book entry "John Smith" and the other one "John the flaming idiot". If you are using free CAs which hand out certs to anyone, an rfc822 address is just clutter which shortens the lifetime of the cert. It doesn't make the two Johns any more unique than they were without it. Saying "John could receive email at this address at the time this cert was issued" links the cert to a non-secure pre-S/MIME rfc822 persona, but the reliability of that link is questionable, particularly if anything more than net reputation is at stake. If you are relying on CAs to provide a real PK Infrastructure (by ensuring that keyholders are tied to something with Identity significance such as a DUNS number or an employment record), then rfc822 addresses are obviously irrelevant. From owner-ietf-smime Wed Feb 9 18:42:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA12317 for ietf-smime-bks; Wed, 9 Feb 2000 18:42:32 -0800 (PST) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12306 for ; Wed, 9 Feb 2000 18:42:28 -0800 (PST) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.9.3/8.9.3) with ESMTP id MAA01157; Thu, 10 Feb 2000 12:45:17 +1000 (EST) Message-Id: <200002100245.MAA01157@typhoon.dstc.qut.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "David P. Kemp" cc: ietf-smime@imc.org Subject: Re: Problem for public CAs In-reply-to: Your message of "Wed, 09 Feb 2000 19:02:34 EST." <200002100002.TAA12163@ara.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Feb 2000 12:45:17 +1000 From: Dean Povey Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >If the message you received from "js" is an S/MIME message, only one >cert will validate the signature or decrypt the body, so you know >which DN is correct. Yes, but you still don't know if that was the correct DN for the email address. You have to guess that the DN "matches" the email address, unless you have some other information. >How does the person who owns js@acme.com get involved in the first place? > >If a hacker sends you an S/MIME message with the hacker's cert, >you can reply to it "securely" (with a message the hacker can decode). >What motivation is there for the hacker to cause the reply to be >delivered to "js@acme.com" where, presumably, the hacker can't get >it and the "real" js can't decrypt it? Because the hacker can get you to reveal some information that you might reveal to js but not to the hacker. I can think of scenarios where this might happen, for example you come to trust someone on a mailing list, but you only associate them with their email address and common name. The hacker learns this and uses this to socially engineer you via email to send him/her some information. You figure, okay well it's encrypted so I'm safe, and the DN kind of looks okay, so I'll send it. >You bootstrap an electronic identity by what you say. If I send out >signed S/MIME messages all of which can be verified by the same cert, >it doesn't matter whether some of them come from a home rfc822 address >and others come from a work rfc822 address. If I want them linked to >the same persona I'll use the same cert. It also doesn't matter >whether the DN is a name with physical significance or a 'nym. All that >matters is that the messages come from the possessor of one private key. >If you have a collection of S/MIME messages with two different certs, >with similar or even identical DNs: > > C=AU, OU=Accounting, O=ACME, CN=John Smith (issuer A, public key X) > C=AU, OU=Accounting, O=ACME, CN=John Smith (issuer B, public key Y) > >you will have enough context to label one address book entry "John Smith" >and the other one "John the flaming idiot". Sure, that is nice in theory, but if there is nothing meaningful in the Certificate to associate with the possessor of the private key then what have you gained? All you know is: a) The person who sent you email message has a private key; and b) That some third party has verified that the person that sent you the email possesses the private key. The email address could be forged and the DN might be meaningless. Now what you are saying is that you associate this DN locally with your address book, mapping the meaningless DN back to a name/context you understand. Therefore you have verified by some out-of-band mechanism that you can associate the public key with a person/entity you know about (via the indirect route of associating them with the meaninglyess DN). So in effect you have negated the need for a third-party certificate in the first place as you have already obtained all the information you needed OOB. Therefore this negates the need to publish the certificate in a public repository, and hence the reason for leaving it out in the first place. Your argument seems to predicated on the basis that I know the people personally with whom I communicate via email. More often than not I am communicating with people via email whom I have never met, and who I know very little about. I sometimes come to trust these people through the email that they send, i.e. I find the things they say knowlegeable or insightful. Therefore I build a certain degree of trust on the basis of this past experience, but I only associate that with their email address and name, not with their DN. My point is that it is not possible to unambiguously associate a DN with an email address, so you can't make this leap without both being in a cert. Therefore I am not going to send some one some secure data on the basis of just a DN if I have nothing to associate it with. Now you could argue that there are some cases where you don't need to verify this binding if you have the context required to get the DN anyway, so therefore it should not be mandated. But this is a relying party decision, not the decision of the person who signs the email. I think you limit the ability of the relying party to make decisions about their email if you don't associate the From address with the signature. Every email address must have a From: address, and I think it is reasonable that this email address in a secure message should always be securely verifiable, so that you can accurately bind an S/MIME message with its point of origin. >If you are using free CAs which hand out certs to anyone, an rfc822 >address is just clutter which shortens the lifetime of the cert. It >doesn't make the two Johns any more unique than they were without it. >Saying "John could receive email at this address at the time this cert >was issued" links the cert to a non-secure pre-S/MIME rfc822 persona, >but the reliability of that link is questionable, particularly if >anything more than net reputation is at stake. This is a valid point. One my misgivings with X.509 is that they chose not to separate attribute and key management (SPKI is much better about this). While S/MIME has support for attribute certs that could be used to associate email addresses with keys in identity certs (useful as these will have different life-cycles), I don't think that the application support is wide enough yet that this is really a valid alternative to putting the email address in the certificate. >If you are relying on CAs to provide a real PK Infrastructure (by ensuring >that keyholders are tied to something with Identity significance such >as a DUNS number or an employment record), then rfc822 addresses are >obviously irrelevant. Well actually what I think you are really after is associate a key holder with something (i.e. a privilege, identity or attribute). But the point is about rfc822 addresses is that this is something you just about always need to verify. Cheers. -- Dean Povey, | e-m: povey@dstc.edu.au | JCSI: Java Crypto Toolkit Research Scientist | ph: +61 7 3864 5120 | security.dstc.edu.au/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - C++ PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ From owner-ietf-smime Thu Feb 10 09:01:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05483 for ietf-smime-bks; Thu, 10 Feb 2000 09:01:54 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05479 for ; Thu, 10 Feb 2000 09:01:53 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA03459 for ; Thu, 10 Feb 2000 12:05:24 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA03455 for ; Thu, 10 Feb 2000 12:05:23 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA01327 for ; Thu, 10 Feb 2000 12:05:19 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id MAA12559 for ; Thu, 10 Feb 2000 12:02:43 -0500 (EST) Message-Id: <200002101702.MAA12559@ara.missi.ncsc.mil> Date: Thu, 10 Feb 2000 12:02:43 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Problem for public CAs To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DMUoRIEvVpj0qCoQTAZrzw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RFC 2632 is fairly clear on the requirements for email addresses: 3. Using Distinguished Names for Internet Mail End-entity certificates MAY contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of that specification. The email address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name. Receiving agents MUST recognize email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field in the PKCS #9 emailAddress attribute. Sending agents SHOULD make the address in the From or Sender header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details. It should be obvious, but apparently is not, that "Sending and receiving agents MUST accept certificates that do not contain an email address in either the subject distinguished name or the subjectAltName extension." For the son of RFC 2632, I propose: 1) appending a sentence to that effect to the first paragraph of section 3. 2) changing the last sentence of the third paragraph from SHOULD to MUST: "A receiving agent MUST provide some explicit alternate processing ..." Individual communities of interest will profile whether their CAs populate the subjectAltName extension, based on their judgement of whether it is a benefit or an operational headache and security risk. I just want to ensure that community-specific CAs have that choice, and are not forced to populate the extension by a proliferation of non-compliant user agents. From owner-ietf-smime Thu Feb 10 09:05:02 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA05563 for ietf-smime-bks; Thu, 10 Feb 2000 09:05:02 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05558 for ; Thu, 10 Feb 2000 09:04:58 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <1JW624T9>; Thu, 10 Feb 2000 12:07:33 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF31965980@wfhqex03.wang.com> From: "Pawling, John" To: "'SMIME WG'" Subject: v1.5 SFL Freely Available to All!! Date: Thu, 10 Feb 2000 12:07:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and Application Programming Interface (API). The SFL source code files are freely available to everyone from the Fortezza Developer's S/MIME Page (with no password control). On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is no longer password controlled. The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H, 3DES) provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by the RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The SFL uses the VDA-enhanced SNACC v1.3 ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL High- level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); VDA- enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities; test drivers and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Solaris 2.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X S/MIME v2 products. Signed messages have been exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 2630, 2631 and 2634. This testing included the RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We have also performed limited S/MIME v3 testing with Baltimore and Entrust. We are also participating in the IETF S/MIME WG interoperability testing documented in the "Examples of S/MIME Messages" document. We have used the SFL to successfully process all of the correct signedData and envelopedData messages included in the document. We are continuing to set up test config files to use the SFL to test the other cases included in the document such as signed receipts. We also plan to provide sample messages for inclusion in the document. The following enhancements are included in the v1.5 SFL release (compared with the v1.4 release): 1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly processed. 2) Fixed many memory leaks; 3) Full CounterSignature test suite (autohiAllSFLd.cfg); 4) CertificateBuilder utility generates private/public key pairs and certificates (there is a "README.txt" file in the root directory regarding this utility). 5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS #11 crypto library, but this project provides a good template for PKCS #11). We are still testing the PKCS #11 CTIL. 6) Developed new test code and configuration files to implement test cases; and 7) Performed regression testing to ensure that aforementioned enhancements did not break existing SFL functionality. We are still in the process of enhancing and testing the SFL. Future releases will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line utility; modify PKCS #12 code in test utilities to provide interoperable key storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; support for other crypto APIs (possible); and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows and Solaris 2.7, we plan to port the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 (possibly), SCO 5.0 (possibly) and Macintosh (possibly). The following SFL files are available from the Fortezza Developer's S/MIME Page: 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler and Library source code compilable for Unix and MS Windows NT/95/98 that has been enhanced by VDA to implement the Distinguished Encoding Rules. Project files and makefiles are included. This file includes a sample test project demonstrating the use of the SNACC classes. 3) smimeR15.zip: Zip file containing all SFL source code including: SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source code; project files. This file also contains test driver source code, sample CMS/ESS test data and test X.509 Certificates. This file also includes test utilities to create X.509 Certificates that each include a D-H, DSA or RSA public key. SNACC release and debug libraries are compiled for MS Windows NT/95/98. MS Windows NT/95/98 project files and Unix makefiles are included for the SNACC code and Crypto++. 4) smR15CTI.zip: Source code for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11. The Win95/98/NT projects are also included. (NOTE: The Free (a.k.a. Crypto++) CTIL includes VDA-developed source code to use the RSA public key algorithm implemented within the external Crypto++ library. As with all of the external crypto token libraries, the Crypto++ library is not distributed as part of the SFL source code. To use the Crypto++ library with the SFL, the application developer must independently obtain the Crypto++ library from the Crypto++ Web Page and then compile it with the VDA-developed Crypto++ CTIL source code. The RSA public key algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication System and Method". Within the U.S., users of the RSA public key algorithm provided by the external Crypto++ library must obtain a license from RSA granting them permission to use the RSA algorithm.) 5) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. VDA is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License" available from the VDA SFL Page and Fortezza Developer's S/MIME Page. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. For example, the SFL uses the freeware Crypto++ library to obtain 3DES, D-H and DSA. To use the SFL with Crypto++ the vendor must download the Crypto++ freeware library from the Crypto++ Web Page and then compile it with the VDA-developed Crypto++ CTIL source code. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. The SFL documents and VDA-enhanced SNACC source code are also available from the VDA SFL Web Page . All comments regarding the SFL source code and documents are welcome. We recommend that comments should be sent to the imc-sfl mail list. We will respond to all messages on that list. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-ietf-smime Fri Feb 11 09:13:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17837 for ietf-smime-bks; Fri, 11 Feb 2000 09:13:21 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17833 for ; Fri, 11 Feb 2000 09:13:20 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Feb 2000 09:15:57 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <1XY70Y34>; Fri, 11 Feb 2000 09:15:57 -0800 Message-ID: <2DCBFADAFCBBD21189D400805F6FA1AB0E4BBF8B@RED-MSG-12> From: "John Biccum (Data Processing Resources Corp)" To: "'ietf-smime@imc.org'" Cc: "Larry Talbot (Excell Data Corporation)" Subject: cryptographic accelerators Date: Fri, 11 Feb 2000 09:15:54 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does anyone on the list have any experience using hardware cryptographic accelerators such as the Atalla or nCipher devices to generate asymmetrical key pairs? Cryptographic hardware seems close enough to an off-topic subject that I'd prefer off-list replies. From owner-ietf-smime Mon Feb 14 13:39:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA22580 for ietf-smime-bks; Mon, 14 Feb 2000 13:39:47 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22576 for ; Mon, 14 Feb 2000 13:39:46 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <1JW6J5J1>; Mon, 14 Feb 2000 16:42:40 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF319659C0@wfhqex03.wang.com> From: "Pawling, John" To: "'SMIME WG'" Subject: v1.5 SFL Re-Delivered Date: Mon, 14 Feb 2000 16:42:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, We made a mistake when we constructed the smR15CTI.zip file described in the enclosed message. We omitted the CTIL source code. We have re-built, checked and re-delivered a corrected smR15CTI.zip file which is now stored on the Fortezza Developer's S/MIME Page . We also fixed memory leaks in the SFL code that we uncovered during Solaris 2.7 memory leak testing late last week. The memory leak fixes are included in a new smimeR15.zip file also stored on the Fortezza Developer's S/MIME Page. Anybody who downloaded the smR15CTI.zip and smimeR15.zip files prior to the afternoon of 14 February should re-download the new zip files currently stored on the Fortezza Developer's SFL Web Page. We sincerely apologize for any inconvenience caused by this mistake. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ Original message: ===================================================================== All, J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and Application Programming Interface (API). The SFL source code files are freely available to everyone from the Fortezza Developer's S/MIME Page (with no password control). On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is no longer password controlled. The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H, 3DES) provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by the RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The SFL uses the VDA-enhanced SNACC v1.3 ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL High- level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); VDA- enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities; test drivers and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Solaris 2.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X S/MIME v2 products. Signed messages have been exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 2630, 2631 and 2634. This testing included the RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We have also performed limited S/MIME v3 testing with Baltimore and Entrust. We are also participating in the IETF S/MIME WG interoperability testing documented in the "Examples of S/MIME Messages" document. We have used the SFL to successfully process all of the correct signedData and envelopedData messages included in the document. We are continuing to set up test config files to use the SFL to test the other cases included in the document such as signed receipts. We also plan to provide sample messages for inclusion in the document. The following enhancements are included in the v1.5 SFL release (compared with the v1.4 release): 1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly processed. 2) Fixed many memory leaks; 3) Full CounterSignature test suite (autohiAllSFLd.cfg); 4) CertificateBuilder utility generates private/public key pairs and certificates (there is a "README.txt" file in the root directory regarding this utility). 5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS #11 crypto library, but this project provides a good template for PKCS #11). We are still testing the PKCS #11 CTIL. 6) Developed new test code and configuration files to implement test cases; and 7) Performed regression testing to ensure that aforementioned enhancements did not break existing SFL functionality. We are still in the process of enhancing and testing the SFL. Future releases will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line utility; modify PKCS #12 code in test utilities to provide interoperable key storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; support for other crypto APIs (possible); and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows and Solaris 2.7, we plan to port the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 (possibly), SCO 5.0 (possibly) and Macintosh (possibly). The following SFL files are available from the Fortezza Developer's S/MIME Page: 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler and Library source code compilable for Unix and MS Windows NT/95/98 that has been enhanced by VDA to implement the Distinguished Encoding Rules. Project files and makefiles are included. This file includes a sample test project demonstrating the use of the SNACC classes. 3) smimeR15.zip: Zip file containing all SFL source code including: SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source code; project files. This file also contains test driver source code, sample CMS/ESS test data and test X.509 Certificates. This file also includes test utilities to create X.509 Certificates that each include a D-H, DSA or RSA public key. SNACC release and debug libraries are compiled for MS Windows NT/95/98. MS Windows NT/95/98 project files and Unix makefiles are included for the SNACC code and Crypto++. 4) smR15CTI.zip: Source code for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11. The Win95/98/NT projects are also included. (NOTE: The Free (a.k.a. Crypto++) CTIL includes VDA-developed source code to use the RSA public key algorithm implemented within the external Crypto++ library. As with all of the external crypto token libraries, the Crypto++ library is not distributed as part of the SFL source code. To use the Crypto++ library with the SFL, the application developer must independently obtain the Crypto++ library from the Crypto++ Web Page and then compile it with the VDA-developed Crypto++ CTIL source code. The RSA public key algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication System and Method". Within the U.S., users of the RSA public key algorithm provided by the external Crypto++ library must obtain a license from RSA granting them permission to use the RSA algorithm.) 5) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. VDA is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License" available from the VDA SFL Page and Fortezza Developer's S/MIME Page. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. For example, the SFL uses the freeware Crypto++ library to obtain 3DES, D-H and DSA. To use the SFL with Crypto++ the vendor must download the Crypto++ freeware library from the Crypto++ Web Page and then compile it with the VDA-developed Crypto++ CTIL source code. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. The SFL documents and VDA-enhanced SNACC source code are also available from the VDA SFL Web Page . All comments regarding the SFL source code and documents are welcome. We recommend that comments should be sent to the imc-sfl mail list. We will respond to all messages on that list. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-ietf-smime Mon Feb 14 15:07:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA24327 for ietf-smime-bks; Mon, 14 Feb 2000 15:07:45 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA24323 for ; Mon, 14 Feb 2000 15:07:44 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Feb 2000 16:10:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 14 Feb 2000 16:10:05 -0700 From: "Bob Jueneman" To: , Subject: Re: Problem for public CAs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA24324 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This has been a fascinating discussion, in part because of the multi-dimensional aspects to the problem. Let me see if I can summarize some of the different points of view: The first issue raised was one of privacy, and in particular the possibility of spam. This reminds me of two lessons I learned so time ago, rather forcefully, with regard to this space. Back in the PEM days, I was concentrating on the question of how to ensure the legal sufficiency of a digital signature to assure nonrepudiation, and I was suggesting that full name, verified address, and perhaps social security number or driver's license number be included in the certificate. John Gilmore brought me up short by pointing out that we were supposed to be talking about privacy ENHANCED mail. Point taken -- some of this stuff needs to be optional. Then a few years later, I was trying to solve the problem of uniquely identifying someone in a directory, given the presumption at the time that multiple directory service providers (e.g., telcos) might exist and might have overlapping geopolitical boundaries. The answer to this problem, it seemed to me, was to include sufficient disambiguating information, such as street address, assuming that there wouldn't be two people with the same name in the same household. Sharon Boyen gave me another much needed lesson in political correctness by pointing out that many women, in particular, weren't about to list their residence address in a public directory, and many wouldn't even list their given names, preferring to be listed as "M. Smith". Point taken again. If necessary, include meaningless qualifiers such as employeeID for uniqueness. So these are legitimate issues, and I suppose that spam mail is the virtual equivalent of stalking. So I accept the position that says that an e-mail address should not be required, either in the DN or the subjectAltName, although it may be desirable. This bears on the second issue, which I raised at the November meeting, where I pointed out that it was all too easy to manipulate the From address in an e-mail so that the addr-spec portion would match the e-mail address in the certificate, and yet the user-friendly portion of the name could be completely bogus and seriously misleading. I now think that I agree with David Kemp -- this is primarily a man/machine interface issue. In other words, the conventional paradigm of presenting the From address as the primary identification of the sender is WRONG in the case of a digitally signed message, and especially so considering how easily it can be forged or manipulated. Instead, in the case of a signed message the From address should be viewed as secondary, and the certificate contents the primary information. The "contents": in this case should probably include the DN and the subjectAltName, even if it takes an additional line of the GUI display. Of course, we have to face the fact that NEITHER the DN nor the RFC822 address may be particularly relevant or informative. In the case of the DN, at least from the perspective of someone who works for a directory company, the DN is probably going to be whatever it is today, not withstanding the fact that directories today are primary set up for the convenience of the system administrator, and secondly for the benefit of users within the organization, and thirdly if at all for the benefit of users outside of the organization. In my case, for example, my directory name is bjueneman.nsrd.prv.novell (note the "backwards" presentation order), or o=Novell, ou=prv, ou=nsrd, cn=bjueneman. Hardly very helpful to someone on the outside, and certainly not what I would like, but unlikely to change any time soon. Of course, bjueneman@novell.com isn't very helpful either, but better than graybeard123@aol.com. (Public CAs may not have this problem, as they would tend to put "meaningful" names in a directory.) So the ugly fact of the matter is that both DNs and RFC822 names are really the result of legacy systems, and are unlikely to change or to be very helpful. So neither is really satisfactory. My preferred solution? Use an _additional_ subjectAltName to convey the person's "real" name, suitably qualified if desired. And leave the directory DN to the directory administrators, and the RFC822 name to e-mail administrators. Render unto Caesar .... Then in the message display, present the subjectAltName containing a commonName format as primary (if present), the RFC822 address as secondary (if present), and the DN as supplemental information (if present). IN order to assure at least some semblance of uniqueness, either the RFC822 name or the DN MUST be present, and the "real" commonName SHOULD be present. The banner portion of a signed message from me would then be properly displayed as: Signer: Robert R. (Bob) Jueneman [bjueneman@novell.com] [o=Novell, ou=prv, ou=nsrd, cn=bjueneman] The From address, i.e., what the RFC822 From address itself was, would not normally be displayed, except by viewing the message in RFC822 format. I believe that the combination of these three different name forms will be sufficient to adequately disambiguate the sender of a message, and to prevent all sorts of mischief and possible accidents. If this is the display format, I don't care that much about what the name matching rules are, or even whether name matching is done at all. So far, name matching seems to be causing more problems than it solves. Comments? Bob From owner-ietf-smime Mon Feb 14 15:56:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25435 for ietf-smime-bks; Mon, 14 Feb 2000 15:56:30 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25431 for ; Mon, 14 Feb 2000 15:56:28 -0800 (PST) Message-Id: <4.2.1.20000214155658.03fabec0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 14 Feb 2000 16:01:05 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Problem for public CAs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Tue Feb 15 02:25:31 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA16729 for ietf-smime-bks; Tue, 15 Feb 2000 02:25:31 -0800 (PST) Received: from citicorp.com (mango2-a.citicorp.com [192.193.196.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16725 for ; Tue, 15 Feb 2000 02:25:29 -0800 (PST) From: bartley.o'malley@citicorp.com Received: from myrtle2.citicorp.com (imta.citicorp.com [192.193.195.189]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12103 for ; Tue, 15 Feb 2000 05:26:17 -0500 (EST) Received: from x400prod2.cgin.us-md.citicorp.com (root@wtprod2.cgin.us-md.citicorp.com [163.39.141.206]) by myrtle2.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12025 for ; Tue, 15 Feb 2000 05:29:21 -0500 (EST) Received: from mercury.lew.gb.citicorp.com (root@mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA03863 Tue, 15 Feb 2000 05:29:20 -0500 (EST) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02037 for ietf-smime@imc.org; Tue, 15 Feb 2000 10:29:17 GMT X-OpenMail-Hops: 1 Date: Tue, 15 Feb 2000 10:29:11 +0000 Message-Id: Subject: RE: Re: Problem for public CAs MIME-Version: 1.0 TO: ietf-smime@imc.org Content-Type: multipart/mixed; boundary="openmail-part-10d68c22-00000001" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --openmail-part-10d68c22-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium --openmail-part-10d68c22-00000001 Content-Type: application/ms-tnef; name="WINMAIL.DAT" Content-Disposition: attachment; filename="WINMAIL.DAT" Content-Transfer-Encoding: base64 eJ8+IqQ+AQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABAB8AAABSRTogUmU6IFByb2JsZW0gZm9y IHB1YmxpYyBDQXMA8AkBA5AGABAAAAABAAAAQAA5ADBk+lKfd78BMAQBA5AGABQAAAABAAAA HgBCEAEAAAABAAAAAAAAAHMAAQOQBgAoAAAAAQAAAAIBcQABAAAAFgAAAAG/d59S2Kok4d/j jhHTsPgAAfrU+5YAAHcNAQOQBgAwAAAAAQAAAB4AcAABAAAAHwAAAFJFOiBSZTogUHJvYmxl bSBmb3IgcHVibGljIENBcwAAnwoBA5AGAEAAAAABAAAAAgExAAEAAAAtAAAANC4yLjEuMjAw MDAyMTQxNTU2NTguMDNmYWJlYzAoYSltYWlsLmltYy5vcmcAAAAALwwBA5AGAAwAAAABAAAA CwACAAEAAAAPAAEDkAYADAAAAAEAAAADAC4AAAAAADIAAQOQBgAYAAAAAQAAAB4APQABAAAA BQAAAFJFOiAAAAAAUwEBA5AGACwAAAABAAAAHgCZCgggBgAAAAAAwAAAAAAAAEYAAAAAOIUA AAEAAAABAAAAAAAAALUCAQOQBgAsAAAAAQAAAB4AmgoIIAYAAAAAAMAAAAAAAABGAAAAADeF AAABAAAAAQAAAAAAAAC1AgEDkAYALAAAAAEAAAAeAJsKCCAGAAAAAADAAAAAAAAARgAAAAA2 hQAAAQAAAAEAAAAAAAAAtQIBA5AGACQAAAABAAAAAwCcCgggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAB7AgEDkAYAJAAAAAEAAAADAJ0KCCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAA AHUCAQOQBgAkAAAAAQAAAAMAngoIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAdQIBA5AG ACQAAAABAAAACwCfCgggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAB8AgEDkAYAJAAAAAEA AAADAKAKCCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAGgCAQOQBgAwAAAAAQAAAB4AoQoI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAApwMBA5AGACQAAAABAAAA AwCiCgggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPMVAADDAwEDkAYAIAAAAAEAAAACAQswAQAA ABAAAADL4SSqjuPTEbD4AAH61PuWJwoBA5AGAAwAAAABAAAAAwCAEP////+QBAEJAAQAAgAA AAAAAAABA5AGAAwAAAABAAAACwAjAAAAAAAvAAEDkAYADAAAAAEAAAALACkAAAAAADUAAQSQ BgDYAQAAAQAAABIAAAAeAAEwAQAAAA0AAAAnaWV0Zi1zbWltZScAAAAAAgH/DwEAAAA7AAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1zbWltZQBTTVRQAGlldGYtc21pbWVAaW1j Lm9yZwAAAwAVDAEAAAADAAAwAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgAaDAEAAAATAAAA TydNYWxsZXksIEJhcnRsZXkAAAACARkMAQAAAD8AAAAAAAAAjVVM0Ow8Ec6B/wgACbEDegEA AAALAAAAAAAAADEdTydNYWxsZXkeMh1CYXJ0bGV5HjUdNjBFVUxPTgAAHgADMAEAAAATAAAA aWV0Zi1zbWltZUBpbWMub3JnAAADAP9fAAAAAAMA/V8BAAAAHgD2XwEAAAALAAAAaWV0Zi1z bWltZQAAAgH3XwEAAAA7AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1zbWltZQBT TVRQAGlldGYtc21pbWVAaW1jLm9yZwAACwAPDgAABIACAQswAQAAABgAAABTTVRQOklFVEYt U01JTUVASU1DLk9SRwADAP4PBgAAAAMAADkAAAAACwBAOgEAEgADAHE6AAAAAAxc --openmail-part-10d68c22-00000001-- From owner-ietf-smime Tue Feb 15 16:50:53 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA08720 for ietf-smime-bks; Tue, 15 Feb 2000 16:50:53 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08716 for ; Tue, 15 Feb 2000 16:50:52 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 15 Feb 2000 17:53:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 15 Feb 2000 17:53:27 -0700 From: "Bob Jueneman" To: Subject: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA08717 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Feb 16 02:23:36 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA27804 for ietf-smime-bks; Wed, 16 Feb 2000 02:23:36 -0800 (PST) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27798 for ; Wed, 16 Feb 2000 02:23:24 -0800 (PST) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 16 Feb 00 10:37:06 -0000 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: from piers2k (host62-172-80-119.host.btclick.com [62.172.80.119]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DW0Z0Y61; Wed, 16 Feb 2000 10:22:41 -0000 Reply-to: piers@bj.co.uk From: "Piers Chivers" To: "'Bob Jueneman'" , ietf-smime@imc.org Subject: RE: E-mail address validation Date: Wed, 16 Feb 2000 10:27:30 -0000 Message-ID: <000301bf7868$6e7ef850$1a01a8c0@piers2k.bj.co.uk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal X-WSS-ID: 14B4A25829729-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, I thought this group was concerned about protocol whereas what you are describing is largely human-machine-interface issues. If we are going to get into that arena I could argue that all signed receipts should be displayed as green. I expect that suggestion would be unacceptable to those who like red! Having said that, I think the addressing issues need to be clarified. We have the added complication of combining SMIME and X.400 where there are both P1 and P2 addresses. I mostly agree with your suggestions below but think they need to be worked upon to become definitive. I'm not sure if this WG is the right forum for that discussion? The most difficult approach is to educate users that who routed the message (the envelope addressees) is not necessarily the same as who generated the content. Perhaps our UIs should improve to make this distinction more explicit. Piers -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Bob Jueneman Sent: 16 February 2000 00:53 To: ietf-smime@imc.org Subject: E-mail address validation Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Feb 16 07:35:57 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA05578 for ietf-smime-bks; Wed, 16 Feb 2000 07:35:57 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05574 for ; Wed, 16 Feb 2000 07:35:56 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08238 for ; Wed, 16 Feb 2000 10:39:56 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA08230 for ; Wed, 16 Feb 2000 10:39:55 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA10253 for ; Wed, 16 Feb 2000 10:39:47 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA15009 for ; Wed, 16 Feb 2000 10:37:01 -0500 (EST) Message-Id: <200002161537.KAA15009@ara.missi.ncsc.mil> Date: Wed, 16 Feb 2000 10:37:01 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: E-mail address validation To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RO+Ll7cTaa/hytNUToLY+w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: "Bob Jueneman" > > [...] > > So let me take a stab at a revised solution that includes both problems, > although this may turn out to be only half-baked. > > 1. The UI for a signed message SHOULD display the originator's "real" common > name, which may be further qualified, if desired. The originator's RFC822 address > from the certificate should also be displayed, and the DN as well, in that order of > preference if those fields are all supplied, but it must be recognized that some > may be missing. Bob, I'm unconvinced that X.509/PKIX/SMIME should define an extension or GeneralName field to contain a "real" common name. That would create more problems than it solves. Yes, there are unusual directory schemas out there, including within the DoD, and they have a substantial amount of inertia. But if there is a corporate policy determination that the "real" common name should be contained in PKI certificates, then it unquestionably would be easier to place it in the CN field of the DN than to procure CAs, directories, and applications with support for an as-yet-undefined field or extension. My stab is that by default the UI should display the Subject CN (always) and the rfc822 address (if present in the cert), with a way for the user to display the full Subject DN or the full cert. If the CN is a bit cryptic, it's up to the organization's CIO to change the schema or leave it as is. Regardless of whether the DN is cryptic or clear, the address book nickname for that cert will always be displayed. > 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from > the certificate to the From address of the message, and SHOULD flag a mismatch, > but MUST NOT require that the RFC822 name be present in the certificate. > > 3. In the event of an encrypted message, including a reply to a From or Reply-to > address, the To, Cc, and Bcc addresses SHOULD all be matched against the > RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE > WAS SELECTED, and SHOULD flag any mismatch with a warning message. > > Does this take care of the problem? Do we need to say something about > checking the outgoing From or Reply-to addresses in the case of a signed message > to make sure they conform to the user's certificate? If so, which certificate -- the > signing certificate, or the encryption certificate? > > Hmm. This gets more and more complicated. > > Bob Don't forget that a single S/MIME message can have multiple nested encryptedData and signedData layers, and that a single signedData can have multiple SignerInfos. Makes the Reply-to, CC, and BCC questions sound simple :-). Paul makes a distinction between the "security standpoint" and the "UI standpoint". I agree with Paul that from the UI standpoint a cert address is not the primary source of return address information. I don't agree that the "security standpoint" is different - if you want a secure Reply-to field, then use signed rfc822 headers, not the contents of the signing cert. My bank will accept a check with my signature without caring whether it entered the postal system from my home address, even though the address is imprinted. The imprinted address serves to identify me, but doesn't limit where I can send or receive snail mail. From owner-ietf-smime Wed Feb 16 11:54:55 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA10831 for ietf-smime-bks; Wed, 16 Feb 2000 11:54:55 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10827 for ; Wed, 16 Feb 2000 11:54:54 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Feb 2000 12:57:52 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 16 Feb 2000 12:55:52 -0700 From: "Bob Jueneman" To: , Subject: Re: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10828 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, the syntax for subjectAltName already includes directoryName, so no architectural extension is required. And multiple subjectAltNames are also allowed, explicitly, so no extension is required there either. Now, how many of the existing mail clients support this is a different question, as is the issue of how many CAs support it. Probably none, in fact. But that's to be expected, especially in a standards group. We are trying to decide where we need to go -- if we limit ourselves to existing products and procurement questions, the game is already over. Naturally, I would like to see CIOs change their directory structure to be more accommodating to what certificates need in terms of conveying useful information to relying parties. The problem is, having observed this phenomenon for nearly 10 years now, I haven't seen any movement in that direction at all, and it isn't just intransigence -- there are copious real reasons why directory schemas are what they are, and they aren't terribly likely to change, I'm afraid. So I'm not trying to reinvent the wheel, just trying to take advantage of the wheels that already exist. Your point about message enveloping is quite valid, and tends to make the address comparison issue even more complicated. Bob >>> "David P. Kemp" 02/16/00 08:37AM >>> > From: "Bob Jueneman" > > [...] > > So let me take a stab at a revised solution that includes both problems, > although this may turn out to be only half-baked. > > 1. The UI for a signed message SHOULD display the originator's "real" common > name, which may be further qualified, if desired. The originator's RFC822 address > from the certificate should also be displayed, and the DN as well, in that order of > preference if those fields are all supplied, but it must be recognized that some > may be missing. Bob, I'm unconvinced that X.509/PKIX/SMIME should define an extension or GeneralName field to contain a "real" common name. That would create more problems than it solves. Yes, there are unusual directory schemas out there, including within the DoD, and they have a substantial amount of inertia. But if there is a corporate policy determination that the "real" common name should be contained in PKI certificates, then it unquestionably would be easier to place it in the CN field of the DN than to procure CAs, directories, and applications with support for an as-yet-undefined field or extension. My stab is that by default the UI should display the Subject CN (always) and the rfc822 address (if present in the cert), with a way for the user to display the full Subject DN or the full cert. If the CN is a bit cryptic, it's up to the organization's CIO to change the schema or leave it as is. Regardless of whether the DN is cryptic or clear, the address book nickname for that cert will always be displayed. > 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from > the certificate to the From address of the message, and SHOULD flag a mismatch, > but MUST NOT require that the RFC822 name be present in the certificate. > > 3. In the event of an encrypted message, including a reply to a From or Reply-to > address, the To, Cc, and Bcc addresses SHOULD all be matched against the > RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE > WAS SELECTED, and SHOULD flag any mismatch with a warning message. > > Does this take care of the problem? Do we need to say something about > checking the outgoing From or Reply-to addresses in the case of a signed message > to make sure they conform to the user's certificate? If so, which certificate -- the > signing certificate, or the encryption certificate? > > Hmm. This gets more and more complicated. > > Bob Don't forget that a single S/MIME message can have multiple nested encryptedData and signedData layers, and that a single signedData can have multiple SignerInfos. Makes the Reply-to, CC, and BCC questions sound simple :-). Paul makes a distinction between the "security standpoint" and the "UI standpoint". I agree with Paul that from the UI standpoint a cert address is not the primary source of return address information. I don't agree that the "security standpoint" is different - if you want a secure Reply-to field, then use signed rfc822 headers, not the contents of the signing cert. My bank will accept a check with my signature without caring whether it entered the postal system from my home address, even though the address is imprinted. The imprinted address serves to identify me, but doesn't limit where I can send or receive snail mail. From owner-ietf-smime Wed Feb 16 12:05:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA11071 for ietf-smime-bks; Wed, 16 Feb 2000 12:05:12 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11066 for ; Wed, 16 Feb 2000 12:05:10 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Feb 2000 13:08:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 16 Feb 2000 13:07:59 -0700 From: "Bob Jueneman" To: , Subject: RE: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA11068 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Piers, I certainly agree that the IETF is primarily concerned with protocols, and not APIs and even less issues of look and feel. However, what we are trying to do is to establish an infrastructure for _secure_ communications, and to a very large extent that security is quite literally in the eye of the beholder. To my mind, S/MIME today 'works" but is not "workable", in part because of the difficulty in setting up the infrastructure, but in part because of trying to get these kinds of nuances right. it could be argued that address verification isn't even necessary -- the user could check the certificate whenever it seemed necessary. But what I really don't want to see is a case where a naive user is tricked into accepting a signed message from "President William C. Clinton" .............. just because foo@bar.com had previously been validated in a different context. So, I believe, the human factors issue is important, and at least as relevant to this WG as any other standards issue where the word "SHOULD" is used. Obviously Novell could go off and do its own thing in this space -- the Internet police aren't going to prevent it if we support an additional user name in a subjectAltName in the certificate, and choose to display it in GroupWise. But I'm trying to raise all of the boats, by making sure that the PKI and S/MIME products not only interoperate, but actually do something useful, and don't mislead people. My two cents, anyway. Bob >>> "Piers Chivers" 02/16/00 03:27AM >>> Bob, I thought this group was concerned about protocol whereas what you are describing is largely human-machine-interface issues. If we are going to get into that arena I could argue that all signed receipts should be displayed as green. I expect that suggestion would be unacceptable to those who like red! Having said that, I think the addressing issues need to be clarified. We have the added complication of combining SMIME and X.400 where there are both P1 and P2 addresses. I mostly agree with your suggestions below but think they need to be worked upon to become definitive. I'm not sure if this WG is the right forum for that discussion? The most difficult approach is to educate users that who routed the message (the envelope addressees) is not necessarily the same as who generated the content. Perhaps our UIs should improve to make this distinction more explicit. Piers -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Bob Jueneman Sent: 16 February 2000 00:53 To: ietf-smime@imc.org Subject: E-mail address validation Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Feb 17 00:00:46 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA13800 for ietf-smime-bks; Thu, 17 Feb 2000 00:00:46 -0800 (PST) Received: from server1.controlnet.co.in (controlnet.co.in [202.54.116.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13796 for ; Thu, 17 Feb 2000 00:00:41 -0800 (PST) Received: from snprobe1 (snprobe1 [192.168.1.252]) by server1.controlnet.co.in (8.8.7/8.8.7) with SMTP id NAA11548 for ; Thu, 17 Feb 2000 13:20:37 +0530 Message-ID: <012801bf78b9$0d1f9640$fc01a8c0@controlnet.co.in> From: "George Da'Costa" To: Subject: wanted help on fletchers checksum urgently ! Date: Thu, 17 Feb 2000 01:34:37 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01BF78E7.26CB9D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0125_01BF78E7.26CB9D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi !!! well i would be glad if i could get some help on fletchers checksum = algorithm. when checking the checksum for ospf lsa header template which bytes of = the packet need to be considered =20 Any help and references are welcome. Thanx in advance. =20 Regards, George =20 =20 =20 ------=_NextPart_000_0125_01BF78E7.26CB9D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi !!!
well i would be glad if i = could get some=20 help on fletchers checksum algorithm.
when checking the checksum for = ospf lsa=20 header template which bytes of the
packet need to be=20 considered
 
Any help and references are welcome. Thanx in=20 advance.
 
Regards,
George
 
 
 
------=_NextPart_000_0125_01BF78E7.26CB9D40-- From owner-ietf-smime Thu Feb 17 05:51:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22867 for ietf-smime-bks; Thu, 17 Feb 2000 05:51:09 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22863 for ; Thu, 17 Feb 2000 05:51:08 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 0B43D2BA; Thu, 17 Feb 2000 08:53:59 -0500 (EST) Received: from excreo-gh01.reo.dec.com (unknown [16.41.128.40]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id B3FCF3CF for ; Thu, 17 Feb 2000 08:53:58 -0500 (EST) Received: by EXCREO-GH01 with Internet Mail Service (5.5.2650.21) id <10Y4HCDS>; Thu, 17 Feb 2000 13:53:57 -0000 Message-ID: <6B180991CB19D31183E40000F86AF80E2873BE@broexc2.bro.dec.com> From: "De Clercq, Jan" To: "'ietf-smime@imc.org'" Subject: S/MIME and disclaimer Date: Thu, 17 Feb 2000 13:53:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there a way to add a generic disclaimer to S/MIME mail messages after the message has been encrypted / signed? This could happen e.g. on the gateway level... Is there a way to extend multipart MIME messages? Is there a way to add scoping to an S/MIME MIME type? Otherwise text added after the S/MIME operations would invalidate the signature. Would a disclaimer added after signing be readable on the receiver side? Tx, Jan From owner-ietf-smime Wed Feb 23 03:19:10 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA22612 for ietf-smime-bks; Wed, 23 Feb 2000 03:19:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22607 for ; Wed, 23 Feb 2000 03:19:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18210; Wed, 23 Feb 2000 06:23:10 -0500 (EST) Message-Id: <200002231123.GAA18210@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-02.txt Date: Wed, 23 Feb 2000 06:23:10 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Incorporation of IDEA Encryption Algorithm in S/MIME Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-02.txt Pages : 6 Date : 22-Feb-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional algorithm for symmetric encryption. Today, IDEA is widely applied in electronic business applications. But it is not considered in the specification [SMIME3]. Encryption algorithms are part of an organizations' security policy. Typically, organizations like to have their own preferences in this respect. Therefore, it is beneficial to have the choice between different well-known encryption algorithms. Especially for those organization who make already use of IDEA on a wide scale it is of high interest that IDEA is also available in S/MIME. It is the intention of this memo to provide the OIDs and algorithms required to include IDEA in S/MIME for symmetric content and key encryption. The general functional capabilities and preferences of S/MIME are specified by the registered list of S/MIME object identifiers (OIDs). This list of OIDs is maintained by the Internet Mail Consortium at . The set of S/MIME functions provided by a client is expressed by the S/MIME capabilities attribute. This attribute contains a list of OIDs of supported cryptographic functions. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000222092914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000222092914.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Feb 23 09:54:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28706 for ietf-smime-bks; Wed, 23 Feb 2000 09:54:03 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28702 for ; Wed, 23 Feb 2000 09:54:02 -0800 (PST) Message-Id: <4.2.1.20000223093955.00c4d6e0(null)> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 23 Feb 2000 09:58:46 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: draft-ietf-smime-idea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are a few things in this document that should raise concern. Appendix C states clearly that this is a patented algorithm for which licensing is available. However, it appears that no one has let the IETF Secretariat know that. Nothing about IDEA is listed on . This draft should not be considered until there is a formal statement to the IETF. Parts of the document sounds like a marketing brochure. "Today, IDEA is widely applied in electronic business applications." "Especially for those organization who make already use of IDEA on a wide scale it is of high interest that IDEA is also available in S/MIME." "Experts in cryptography consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. These seem particularly inappropriate for an RFC. To be frank, I've never heard of anyone wanting to use IDEA for anything other than old PGP. The folks who wrote PGP had their reasons for choosing IDEA when they did, but they dropped IDEA as a required algorithm for OpenPGP and that doesn't appear to have negatively affected them. The IETF shouldn't codify this kind of marketing hype, even in an Informational RFC. To move forwards with this, it would be nice if the authors went through the draft and took out the marketing fluff. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Feb 23 11:19:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00526 for ietf-smime-bks; Wed, 23 Feb 2000 11:19:04 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00521 for ; Wed, 23 Feb 2000 11:19:03 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA19155 for ; Wed, 23 Feb 2000 11:18:27 -0800 (PST) Message-Id: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Feb 2000 14:20:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime Wed Feb 23 13:11:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02003 for ietf-smime-bks; Wed, 23 Feb 2000 13:11:21 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01999 for ; Wed, 23 Feb 2000 13:11:20 -0800 (PST) Message-Id: <4.2.1.20000223125743.00c4c310@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 23 Feb 2000 13:16:05 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> References: <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >3. I would like this document to become a Standards Track document. Not to disagree with the WG chair, but it is unclear why this should be on standards track. It is protocol information for the community about a non-mandatory algorithm that, as far as we can tell, is barely used. Because of that, isn't it much better qualified for Informational RFC? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Feb 24 05:52:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA08114 for ietf-smime-bks; Thu, 24 Feb 2000 05:52:55 -0800 (PST) Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08110 for ; Thu, 24 Feb 2000 05:52:54 -0800 (PST) Received: by MARS with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 08:56:47 -0500 Message-ID: From: Aram Perez To: ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea Date: Thu, 24 Feb 2000 08:56:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, Paul and others, Is it possible to create a "template" RFC for using algorithms with S/MIME? The CAST-128 document might be a good starting point. Regards, Aram Perez -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Wednesday, February 23, 2000 2:20 PM To: ietf-smime@imc.org Subject: Re: draft-ietf-smime-idea All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime Thu Feb 24 12:53:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16506 for ietf-smime-bks; Thu, 24 Feb 2000 12:53:48 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16501; Thu, 24 Feb 2000 12:53:46 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA02469; Thu, 24 Feb 2000 12:53:12 -0800 (PST) Message-Id: <4.2.0.58.20000224151110.00a4d610@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 15:14:39 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: draft-ietf-smime-idea Cc: ietf-smime@imc.org In-Reply-To: <4.2.1.20000223125743.00c4c310@mail.imc.org> References: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: Take a look at the cipher suite definitions associated with TLS. Only one cipher suite is mandatory to implement, but all of the cipher suite documents are on standards track. The SKIPJACK and KEA document is an exception. The algorithm to wrap one SKIPJACK key with another SKIPJACK key is not specified in a publicly available document. For this reason, it is not appropriate for the document to be on standards track. All of the information to implement is not provided.... Russ At 01:16 PM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >>3. I would like this document to become a Standards Track document. > >Not to disagree with the WG chair, but it is unclear why this should be on >standards track. It is protocol information for the community about a >non-mandatory algorithm that, as far as we can tell, is barely used. >Because of that, isn't it much better qualified for Informational RFC? > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime Thu Feb 24 13:40:51 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17119 for ietf-smime-bks; Thu, 24 Feb 2000 13:40:51 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17115 for ; Thu, 24 Feb 2000 13:40:49 -0800 (PST) Message-Id: <4.2.1.20000224134352.00c4e6f0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 24 Feb 2000 13:45:51 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.0.58.20000224151110.00a4d610@mail.spyrus.com> References: <4.2.1.20000223125743.00c4c310@mail.imc.org> <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:14 PM 2/24/00 -0500, Russ Housley wrote: >Take a look at the cipher suite definitions associated with TLS. Only one >cipher suite is mandatory to implement, but all of the cipher suite >documents are on standards track. If Johnny jumped off a bridge, would you do it? :-) Other WGs are putting things like this on standards track; I don't think that is necessarily a good idea. This can probably be deferred until you talk with the ADs about what they think. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Feb 24 13:48:46 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17277 for ietf-smime-bks; Thu, 24 Feb 2000 13:48:46 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17273 for ; Thu, 24 Feb 2000 13:48:45 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA03153; Thu, 24 Feb 2000 13:48:11 -0800 (PST) Message-Id: <4.2.0.58.20000224162733.00942b60@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 16:29:08 -0500 To: Aram Perez From: Russ Housley Subject: RE: draft-ietf-smime-idea Cc: ietf-smime@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Aram: The subsection within section 6 of RFC 2630 are a good start. It really depends what kind of algorithm is being specified: encryption, hash, key management, signature, or key wrap. Russ At 08:56 AM 02/24/2000 -0500, Aram Perez wrote: >Hi Russ, Paul and others, > >Is it possible to create a "template" RFC for using algorithms with S/MIME? >The CAST-128 document might be a good starting point. > >Regards, >Aram Perez > > >-----Original Message----- >From: Russ Housley [mailto:housley@spyrus.com] >Sent: Wednesday, February 23, 2000 2:20 PM >To: ietf-smime@imc.org >Subject: Re: draft-ietf-smime-idea > > >All: > >Paul raises some very important points. Let me share my view as the S/MIME >Working Group Chair. > >1. We must have an IPR statement for this document to progress to an RFC. > >2. I do not mind some justification text. Something like: "Organization >who make already use of IDEA for other applications also want to use IDEA >in S/MIME." But, in my opinion, the marketing hype needs to be >significantly reduced. The CAST-128 document does not try to convince >anyone that CAST-128 is appropriate or inappropriate for any particular >group of users. The IDEA document should have a similar tone. > >3. I would like this document to become a Standards Track document. The >document should state the one and only way that IDEA is used with >CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is >implemented, then it MUST be done in the manner specified in this >document. I cannot recommend that this document become a Standards Track >RFC until items 1 and 2 are repaired. > >Russ > > >At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: > >There are a few things in this document that should raise concern. > > > >Appendix C states clearly that this is a patented algorithm for which > >licensing is available. However, it appears that no one has let the IETF > >Secretariat know that. Nothing about IDEA is listed on > >. This draft should not be considered until > >there is a formal statement to the IETF. > > > >Parts of the document sounds like a marketing brochure. "Today, IDEA is > >widely applied in electronic business applications." "Especially for those > >organization who make already use of IDEA on a wide scale it is of high > >interest that IDEA is also available in S/MIME." "Experts in cryptography > >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > > > >These seem particularly inappropriate for an RFC. To be frank, I've never > >heard of anyone wanting to use IDEA for anything other than old PGP. The > >folks who wrote PGP had their reasons for choosing IDEA when they did, but > >they dropped IDEA as a required algorithm for OpenPGP and that doesn't > >appear to have negatively affected them. The IETF shouldn't codify this > >kind of marketing hype, even in an Informational RFC. To move forwards > >with this, it would be nice if the authors went through the draft and took > >out the marketing fluff. > > > >--Paul Hoffman, Director > >--Internet Mail Consortium From owner-ietf-smime Thu Feb 24 22:17:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA07411 for ietf-smime-bks; Thu, 24 Feb 2000 22:17:57 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA07407 for ; Thu, 24 Feb 2000 22:17:56 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2000 23:21:29 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 24 Feb 2000 23:21:13 -0700 From: "Bob Jueneman" To: , Subject: Re: draft-ietf-smime-idea Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA07408 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "The wonderful thing about standards is that there are so many to choose from." I strongly agree with Paul. I am not aware of ANY kind of a significant ground swell for IDEA, especially with the relaxation of the US export regulations and the wider availability of triple-DES and the forthcoming AES algorithm(s). In fact, I think there are already FAR too many algorithms, variations, etc., in the S/MIME standard as it is, and to virtually no good purpose that I can see. Unless a particular algorithm is obviously off the wall, the tendency is for every implementation to include every algorithm, regardless of the actual number of users. Some Program Manager somewhere will say, "But what if customer B want to use algorithm X, and we don't support it. Then customer A would not be able to communicate with him, and we might lose sales." And pretty soon, the product is up to 60 megabytes in size, chock full of unused options, and everyone wonders why the product is so bloated and hard to use, not to mention all of the interoperability problems caused for the customers. It's high time to say ENOUGH, and to kill off this sort of useless nonsense while it is still budding, without consuming useless cycles debating the format of the document, the IPR issues, etc., etc. Bob >>> Paul Hoffman / IMC 02/23/00 10:58AM >>> [snip] To be frank, I've never heard of anyone wanting to use IDEA for anything other than old PGP. The folks who wrote PGP had their reasons for choosing IDEA when they did, but they dropped IDEA as a required algorithm for OpenPGP and that doesn't appear to have negatively affected them. The IETF shouldn't codify this kind of marketing hype, even in an Informational RFC. [snip] --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri Mar 3 06:36:02 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19548 for ietf-smime-bks; Fri, 3 Mar 2000 06:36:02 -0800 (PST) Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19537 for ; Fri, 3 Mar 2000 06:35:58 -0800 (PST) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-5.05) id ADDC18000FE; Fri, 03 Mar 2000 15:36:12 +0100 Received: from PLIPP2 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0alpha3b 1/December/1999); Fr, 03 Mär 2000 15:36:36 +0100 From: "Peter Lipp" To: Subject: AW: draft-ietf-smime-idea Date: Fri, 3 Mar 2000 15:36:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.90086585--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.90086585-- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > In fact, I think there are already FAR too many algorithms, > variations, etc., in the S/MIME standard as > it is, and to virtually no good purpose that I can see. Yes! As long as there is a strong enough free cipher in there, everybody should be happy. Maybe another one to choose from, and yes, as AES becomes a standard, there will be a need to add it(them). What do the ton's of ciphersuites in TLS buy us if there are major vendors only supporting the RSA ones and all the products need to be able to talk to them? Yes, we can say "all ciphersuites implemented in our toolkit"! Peter ______________________________________ Dr. Peter Lipp IAIK, TU Graz Inffeldgasse 16a, A-8010 Graz, Austria Tel: +43 316 873 5513 Fax: +43 316 873 5520 Web: www.iaik.at ----IAIK.SMIME.MAPPER.90086585-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDAzMDMxNDM2MzdaMCMGCSqGSIb3DQEJBDEWBBRHJkBl6UdH6FYn INN7etKR9xgX4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgKKPYVH9JdFcbH9vNbHCubKRr7wA51fOms0eG4bKjFQT xozr9nqZRvfXWN9zwPm/pVM2OmXRFoBEGii8Xusbx5BhFtE9BCfI6P1rD7WdKtAT rBHdzSHWQkqEmQzUjsnOeMX/Siu10VKSdDYnysVr72VMQmfsLsygSzmv3AhsWSFn AAAAAAAA ----IAIK.SMIME.MAPPER.90086585---- From owner-ietf-smime Fri Mar 3 09:56:01 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA04623 for ietf-smime-bks; Fri, 3 Mar 2000 09:56:01 -0800 (PST) Received: from alpha.it-sec.com (dmz1.itsec.ch [195.141.254.202] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04614 for ; Fri, 3 Mar 2000 09:55:58 -0800 (PST) Received: from svzh0004.itsec.ch (localhost [127.0.0.1]) by alpha.it-sec.com (8.9.3/8.9.3) with ESMTP id TAA18455; Fri, 3 Mar 2000 19:54:12 +0100 (MET) Received: by SVZH0004 with Internet Mail Service (5.5.2448.0) id <1PL1SM5Z>; Fri, 3 Mar 2000 18:53:49 +0100 Message-ID: From: "Teiwes, Stephan (iT_SEC)" To: "'Russ Housley'" , ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea Date: Fri, 3 Mar 2000 18:53:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Firstly, I would like to apologize for the delay of my response (I was busy on CeBIT). We highly respect all comments on the draft and would like to proceed in the following way: 1. we will submit an IPR statement to the IETF and this working group very soon 2. we will remove all sentences in the draft which could lead to the impression of marketing; it is not our intention to misuse the draft for marketing purposes I would like to remark that the sentence "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." has been introduced for justification. We sent already an long list of IDEA users in industry to the SMIME working group (also Mr. Hoffman got this list, and thus he should not say that he has never heart of anyone wanting to use IDEA). We can proove that IDEA is widely used in Europe. According to our experience customers in industry often like to choose a symmetric cipher as a part of their security policy. This demand should be considered in SMIME, and that's why we wrote the draft. 3. The short statement and reference on the security of IDEA has been introduced in appendix B when Mr. Hoffman asked us to include such a statement (after submission of draft verion 0). Basically, we reacted on his doubts about the IDEA security. Anyway, we will remove the statement "Experts in cryptography consider IDEA to be a highly secure symmetric cipher [IDEA]" as it can be directly obtained from the stated literature. Despite different personal opinions about the use of IDEA, we believe, the customer's desires should be considered. We can proove that big European companies and banks are using it, and they want to use it in SMIME as well. Thanks a lot for your understanding and support. *Stephan Teiwes, iT_Security AG -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Mittwoch, 23. Februar 2000 20:20 To: ietf-smime@imc.org Subject: Re: draft-ietf-smime-idea All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime Mon Mar 6 03:56:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27216 for ietf-smime-bks; Mon, 6 Mar 2000 03:56:21 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27212 for ; Mon, 6 Mar 2000 03:56:19 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02352; Mon, 6 Mar 2000 06:56:49 -0500 (EST) Message-Id: <200003061156.GAA02352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cast-128-01.txt Date: Mon, 06 Mar 2000 06:56:48 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the CAST-128 Encryption Algorithm in CMS Author(s) : C. Adams Filename : draft-ietf-smime-cast-128-01.txt Pages : 6 Date : 03-Mar-00 This document specifies how to incorporate CAST-128 [RFC2144] into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification [RFC2630] for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cast-128-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000303085824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cast-128-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303085824.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Mar 6 16:21:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10154 for ietf-smime-bks; Mon, 6 Mar 2000 16:21:36 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10150 for ; Mon, 6 Mar 2000 16:21:35 -0800 (PST) Received: from rhousley_laptop.spyrus.com (rhousley-pc.spyrus.com [207.212.34.221]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA21276 for ; Mon, 6 Mar 2000 16:21:37 -0800 (PST) Message-Id: <4.2.0.58.20000306191221.00a44100@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 06 Mar 2000 19:21:17 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Triple Wrapping Survey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a few questions for implementors. First some background, then the questions. The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME encodings. If each of these encodings uses Base64, then the overhead is huge. I am interested in ways to reduce the overhead, hopefully without hurting IMAP usability. 1. Can your implementation handle MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ? The outer SignedData has the OID for EnvelopedData in the content type, not id-data. The EnvelopedData has the OID for SignedData in the content type, not id-data. The inner Signed Data has the id-data OID in the content type. 2. Can your implementation handle MIME without Base64 encoding? I am interested in using "binary" instead of Base64 to reduce the overhead. Russ From owner-ietf-smime Tue Mar 7 06:29:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA15136 for ietf-smime-bks; Tue, 7 Mar 2000 06:29:18 -0800 (PST) Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15131 for ; Tue, 7 Mar 2000 06:29:16 -0800 (PST) Received: by MARS with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 09:29:40 -0500 Message-ID: From: Aram Perez To: ietf-smime@imc.org Subject: RE: Triple Wrapping Survey Date: Tue, 7 Mar 2000 09:29:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I understand MIME, all implementations should handle binary as this is the default unless otherwise specified. Regards, Aram Perez -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Monday, March 06, 2000 7:21 PM To: ietf-smime@imc.org Subject: Triple Wrapping Survey I have a few questions for implementors. First some background, then the questions. The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME encodings. If each of these encodings uses Base64, then the overhead is huge. I am interested in ways to reduce the overhead, hopefully without hurting IMAP usability. 1. Can your implementation handle MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ? The outer SignedData has the OID for EnvelopedData in the content type, not id-data. The EnvelopedData has the OID for SignedData in the content type, not id-data. The inner Signed Data has the id-data OID in the content type. 2. Can your implementation handle MIME without Base64 encoding? I am interested in using "binary" instead of Base64 to reduce the overhead. Russ From owner-ietf-smime Tue Mar 7 12:27:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21856 for ietf-smime-bks; Tue, 7 Mar 2000 12:27:00 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA21852 for ; Tue, 7 Mar 2000 12:26:59 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Tue, 07 Mar 00 12:27:06 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 12:27:06 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C594F827@mail.deming.com> From: "Blake Ramsdell" To: "'Aram Perez'" , ietf-smime@imc.org Subject: RE: Triple Wrapping Survey Date: Tue, 7 Mar 2000 12:26:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 14DBB99082655-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think that the point Russ was making is "can you handle nesting of CMS objects" not "can you handle nesting of MIME wrapped CMS objects". In our case, we can only do MIME wrapped CMS objects, but we can handle binary encoding of those objects. Blake -----Original Message----- From: Aram Perez [mailto:aperez@syndata.com] Sent: Tuesday, March 07, 2000 6:30 AM To: ietf-smime@imc.org Subject: RE: Triple Wrapping Survey Hi Russ, I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I understand MIME, all implementations should handle binary as this is the default unless otherwise specified. Regards, Aram Perez -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Monday, March 06, 2000 7:21 PM To: ietf-smime@imc.org Subject: Triple Wrapping Survey I have a few questions for implementors. First some background, then the questions. The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME encodings. If each of these encodings uses Base64, then the overhead is huge. I am interested in ways to reduce the overhead, hopefully without hurting IMAP usability. 1. Can your implementation handle MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ? The outer SignedData has the OID for EnvelopedData in the content type, not id-data. The EnvelopedData has the OID for SignedData in the content type, not id-data. The inner Signed Data has the id-data OID in the content type. 2. Can your implementation handle MIME without Base64 encoding? I am interested in using "binary" instead of Base64 to reduce the overhead. Russ From owner-ietf-smime Tue Mar 7 15:26:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25393 for ietf-smime-bks; Tue, 7 Mar 2000 15:26:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25389 for ; Tue, 7 Mar 2000 15:26:26 -0800 (PST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29064; Tue, 7 Mar 2000 15:26:53 -0800 (PST) Message-Id: <200003072326.PAA29064@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2785 on Methods for Avoiding "Small-Subgroup" Attacks Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 07 Mar 2000 15:26:53 -0800 From: RFC Editor Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2785 Title: Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME Author(s): R. Zuccherato Status: Informational Date: March 2000 Mailbox: robert.zuccherato@entrust.com Pages: 11 Characters: 24415 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-small-subgroup-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2785.txt In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This document is a product of the S/MIME Mail Security Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000307151835.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2785 --OtherAccess Content-Type: Message/External-body; name="rfc2785.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000307151835.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Mar 9 03:29:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA26215 for ietf-smime-bks; Thu, 9 Mar 2000 03:29:25 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26203 for ; Thu, 9 Mar 2000 03:29:23 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25296; Thu, 9 Mar 2000 06:30:08 -0500 (EST) Message-Id: <200003091130.GAA25296@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-domsec-04.txt Date: Thu, 09 Mar 2000 06:30:08 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Domain Security Services using S/MIME Author(s) : T. Dean, W. Ottaway Filename : draft-ietf-smime-domsec-04.txt Pages : 8 Date : 08-Mar-00 This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely - for example when two domains use incompatible messaging technologies such as X.400 and SMTP/MIME. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-domsec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-domsec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000308132005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-domsec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-domsec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308132005.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Mar 9 08:42:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05059 for ietf-smime-bks; Thu, 9 Mar 2000 08:42:53 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05054 for ; Thu, 9 Mar 2000 08:42:52 -0800 (PST) Received: from rhousley_laptop.spyrus.com (rhousley-pc.spyrus.com [207.212.34.221]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA23349 for ; Thu, 9 Mar 2000 08:43:03 -0800 (PST) Message-Id: <4.2.0.58.20000309113750.00a61330@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Mar 2000 11:39:31 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: LAST CALL: draft-ietf-smime-cast-128-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAST-128 algorithm specification is ready for Working Group Last Call. Please post comments to the ietf-smime mail list before 23 March 2000. Russ = = = = = = = = = = A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the CAST-128 Encryption Algorithm in CMS Author(s) : C. Adams Filename : draft-ietf-smime-cast-128-01.txt Pages : 6 Date : 03-Mar-00 This document specifies how to incorporate CAST-128 [RFC2144] into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification [RFC2630] for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cast-128-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000303085824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt From owner-ietf-smime Thu Mar 9 23:17:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29228 for ietf-smime-bks; Thu, 9 Mar 2000 23:17:41 -0800 (PST) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29224 for ; Thu, 9 Mar 2000 23:17:40 -0800 (PST) Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id XAA10087; Thu, 9 Mar 2000 23:18:26 -0800 (PST) From: "Jim Schaad" Reply-to: jimsch@nwlink.com To: Aram Perez , ietf-smime@imc.org Date: Thu, 9 Mar 2000 23:18:29 +0800 Subject: RE: Triple Wrapping Survey Message-id: <38c8a1c5.105d5.0@nwlink.com> X-User-Info: 210.55.166.93 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Hi Russ, > >I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I >understand MIME, all implementations should handle binary as this is the >default unless otherwise specified. There are some known existing implemenations which cannot correctly handle the binary versions. I do not know any longer how wide spread these versions are. jim > >Regards, >Aram Perez > >-----Original Message----- >From: Russ Housley [mailto:housley@spyrus.com] >Sent: Monday, March 06, 2000 7:21 PM >To: ietf-smime@imc.org >Subject: Triple Wrapping Survey > > >I have a few questions for implementors. First some background, then the >questions. > >The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME >encodings. If each of these encodings uses Base64, then the overhead is >huge. I am interested in ways to reduce the overhead, hopefully without >hurting IMAP usability. > >1. Can your implementation handle > MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ? > >The outer SignedData has the OID for EnvelopedData in the content type, not >id-data. >The EnvelopedData has the OID for SignedData in the content type, not >id-data. >The inner Signed Data has the id-data OID in the content type. > >2. Can your implementation handle MIME without Base64 encoding? I am >interested in using "binary" instead of Base64 to reduce the overhead. > >Russ > > http://www.nwlink.com From owner-ietf-smime Thu Mar 9 23:15:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29161 for ietf-smime-bks; Thu, 9 Mar 2000 23:15:57 -0800 (PST) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29154 for ; Thu, 9 Mar 2000 23:15:56 -0800 (PST) Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id XAA09953; Thu, 9 Mar 2000 23:16:43 -0800 (PST) From: "Jim Schaad" Reply-to: jimsch@nwlink.com To: Russ Housley , ietf-smime@imc.org Date: Thu, 9 Mar 2000 23:16:43 +0800 Subject: Re: Triple Wrapping Survey Message-id: <38c8a15b.105cb.0@nwlink.com> X-User-Info: 210.55.166.93 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Msft versions cannot handle case #1 (I think). Msft versions can handle case #2 without any problems. jim schaad >I have a few questions for implementors. First some background, then the >questions. > >The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME >encodings. If each of these encodings uses Base64, then the overhead is >huge. I am interested in ways to reduce the overhead, hopefully without >hurting IMAP usability. > >1. Can your implementation handle > MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ? > >The outer SignedData has the OID for EnvelopedData in the content type, not >id-data. >The EnvelopedData has the OID for SignedData in the content type, not id-data. >The inner Signed Data has the id-data OID in the content type. > >2. Can your implementation handle MIME without Base64 encoding? I am >interested in using "binary" instead of Base64 to reduce the overhead. > >Russ > > http://www.nwlink.com From owner-ietf-smime Fri Mar 10 03:29:40 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12943 for ietf-smime-bks; Fri, 10 Mar 2000 03:29:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12938 for ; Fri, 10 Mar 2000 03:29:39 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29584; Fri, 10 Mar 2000 06:30:29 -0500 (EST) Message-Id: <200003101130.GAA29584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-esformats-00.txt Date: Fri, 10 Mar 2000 06:30:29 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Electronic Signature Formats for long term electronic signature Author(s) : J. Ross, D. Pinkas, N. Pope Filename : draft-ietf-smime-esformats-00.txt Pages : 106 Date : 09-Mar-00 The informational RFC defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. The contents of this Informational RFC is technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-esformats-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-esformats-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-esformats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-esformats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140444.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Mar 13 03:18:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09568 for ietf-smime-bks; Mon, 13 Mar 2000 03:18:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09563 for ; Mon, 13 Mar 2000 03:18:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15402; Mon, 13 Mar 2000 06:19:39 -0500 (EST) Message-Id: <200003131119.GAA15402@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-password-02.txt Date: Mon, 13 Mar 2000 06:19:38 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Password-based Encryption for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-password-02.txt Pages : 9 Date : 10-Mar-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for password-based data encryption. This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which isn't necessarily an algorithm-specific fixed-format key. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-password-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-password-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-password-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310135126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-password-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-password-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310135126.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Mar 13 03:18:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09560 for ietf-smime-bks; Mon, 13 Mar 2000 03:18:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09556 for ; Mon, 13 Mar 2000 03:18:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15379; Mon, 13 Mar 2000 06:19:34 -0500 (EST) Message-Id: <200003131119.GAA15379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-00.txt Date: Mon, 13 Mar 2000 06:19:33 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS RSAES-OAEP Conventions Author(s) : R. Housley Filename : draft-ietf-smime-cms-rsaes-oaep-00.txt Pages : 8 Date : 10-Mar-00 This document describes the use of the RSAES-OAEP key transport method of key management within the Cryptographic Message Syntax [CMS]. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cms-rsaes-oaep-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310135116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsaes-oaep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310135116.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Mar 13 07:45:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16323 for ietf-smime-bks; Mon, 13 Mar 2000 07:45:56 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16319 for ; Mon, 13 Mar 2000 07:45:55 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA28672; Mon, 13 Mar 2000 07:45:58 -0800 (PST) Message-Id: <4.2.0.58.20000313103421.00a71e60@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 13 Mar 2000 10:43:16 -0500 To: agenda@ietf.org From: Russ Housley Subject: S/MIME WG Agenda Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: S/MIME Mail Security WG Agenda Introductions Russ Housley Working Group Status Russ Housley Security Policies and Labels Russ Housley CERTDIST Draft Discussion Jim Schaad Symmetric Key Distribution Sean Turner DOMSEC Draft Discussion Bill Ottaway Interoperability Matrix Jim Schaad CMS/ESS Examples Paul Hoffman Crypto Algorithm Documents Russ Housley E-mail Addresses & Certificates Greg Colla S/MIME Freeware Library John Pawling Electronic Signature Formats Denis Pinkas Wrap up Russ Housley From owner-ietf-smime Mon Mar 13 12:18:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22696 for ietf-smime-bks; Mon, 13 Mar 2000 12:18:54 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22692 for ; Mon, 13 Mar 2000 12:18:53 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA02350 for ; Mon, 13 Mar 2000 12:19:27 -0800 (PST) Message-Id: <4.2.0.58.20000313151245.0095c7c0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 13 Mar 2000 15:15:34 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: LAST CALL:draft-ietf-smime-password-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Password-based Encryption for S/MIME specification is ready for Working Group Last Call. Please post comments to the ietf-smime mail list before 27 March 2000. Russ = = = = = = = = = = Title : Password-based Encryption for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-password-02.txt Pages : 9 Date : 10-Mar-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for password-based data encryption. This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which isn't necessarily an algorithm-specific fixed-format key. From owner-ietf-smime Mon Mar 13 14:37:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA26275 for ietf-smime-bks; Mon, 13 Mar 2000 14:37:03 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26038; Mon, 13 Mar 2000 14:32:32 -0800 (PST) Message-Id: <4.3.2.20000313143129.00d4e100@not-real.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 13 Mar 2000 14:33:51 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC Subject: New draft on ASN.1 pitfalls Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timing is everything. Just as the PKIX mailing list starts to talk about ASN.1 again, a new draft comes out that does a good job of listing some of the ASN.1 gotchas to look out for, as well as why ASN.1 isn't necessarily a great format to use (although it's a tad too late for that now...). Anyhow, take a look at . The author said he's open to adding any PKIX-specific and S/MIME-specific warnings to the document. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Mon Mar 13 20:19:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA09781 for ietf-smime-bks; Mon, 13 Mar 2000 20:19:21 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA09774 for ; Mon, 13 Mar 2000 20:19:19 -0800 (PST) Message-Id: <4.3.2.20000313201754.05633800@not-real.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 13 Mar 2000 20:20:38 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: S/MIME examples draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been essentially no input to this draft in a very long time. The vast majority of the input came from Jim Schaad, who is no longer in the S/MIME world. Thus, I believe that the draft is probably dead. If other S/MIME developers want to contribute examples where there are holes and comments for the examples that are there, I'm happy to continue the draft, but otherwise we might just let this go away. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Tue Mar 14 06:44:58 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA10164 for ietf-smime-bks; Tue, 14 Mar 2000 06:44:58 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10160 for ; Tue, 14 Mar 2000 06:44:56 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 09:45:41 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF31965BA2@wfhqex01.wangfed.com> From: "Pawling, John" To: ietf-smime@imc.org Subject: S/MIME v3 Interoperability Testing (was RE: S/MIME examples draft ) Date: Tue, 14 Mar 2000 09:45:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul (and friends), We believe that the "Examples of S/MIME Messages" document should be enhanced and maintained. We believe that it is extremely valuable to have a set of properly formatted sample S/MIME messages which can be used to test S/MIME implementations. We have used the S/MIME Freeware Library (SFL) to successfully process (i.e. decode, verify, decrypt) the majority of the samples in the document. I use the term "the majority" because the SFL does not support every S/MIME v3 optional feature. For example, the SFL does not support the CMS authenticatedData content type. We have also used the SFL to construct sample data (such as signed receipts) to be added to the document. We have automated this SFL testing (through the use or test drivers and configuration files) so that it can be easily repeated and modified by us or independently by a third party (we provide all source code, unencumbered). We are willing to spend time providing sample data to be included in the Examples document and to provide support when there are questions regarding the validity of the sample data. We are also willing to participate in interoperability testing with others. We apologize for not providing feedback and submitting sample data sooner. We have been using the SFL to perform S/MIME v3 interoperability testing with Microsoft that has exercised the majority of the features specified by RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS). This testing has included the RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We were waiting until we finished interoperability testing with Microsoft to submit the SFL-produced sample data. Yesterday (3/13/00) we successfully completed RFC 2634 (ESS) signed receipt interoperability testing between the SFL and Microsoft. This was the last major S/MIME v3 item that needed to be tested between the SFL and Microsoft. We plan to provide sample signed receipts for inclusion in the Examples document. We have also performed limited S/MIME v3 testing with Baltimore and Entrust. We still need to perform countersignature interoperability testing. We plan to pursue this testing with Microsoft. If anybody else can process countersignatures, please let us know. We are not going to wait until this testing is done before submitting SFL-produced sample data for inclusion in the Examples document. As many of you know, Jim Schaad created a detailed set of matrices to document the interoperabilty testing performed between various implementations. There is a matrix for each S/MIME v3 specification. These matrices are much more detailed than the "Examples of S/MIME Messages" document. We have verified that the SFL can produce and process the majority of the features documented in the compliance matrices. Again, I use the term "the majority" because the SFL does not support every S/MIME v3 optional feature. We have automated this SFL testing so that it can be easily repeated and modified by us or independently by a third party. We have developed sample objects that illustrate each feature in the matrix that the SFL supports. Please note that Jim Schaad's matrices are a superset of the Examples document. Does the group want to include all of Jim's tests in the Examples document? If so, we can provide the sample data to illustrate each feature in the matrix that the SFL supports. Please note that this document would be huge, but it would provide a comprehensive set of test data. What do others think? We will have the SFL-produced test data ready for distribution by 24 March 2000 at the latest. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-ietf-smime Wed Mar 15 17:17:03 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA22216 for ietf-smime-bks; Wed, 15 Mar 2000 17:17:03 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22201 for ; Wed, 15 Mar 2000 17:17:02 -0800 (PST) Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id RAA02559; Wed, 15 Mar 2000 17:17:39 -0800 (PST) Message-Id: <4.2.0.58.20000315140050.00a509a0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Mar 2000 14:06:49 -0500 To: "Pawling, John" From: Russ Housley Subject: Re: S/MIME v3 Interoperability Testing (was RE: S/MIME examples draft ) Cc: ietf-smime@imc.org In-Reply-To: <33BD629222C0D211B6DB0060085ACF31965BA2@wfhqex01.wangfed.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John: John, as S/MIME WG chairman, I greatly appreciate your commitment. I hope that other implementors will join in this effort. Collecting this data is essential for the specifications to progress from Proposed Standard to Draft Standard, so we might as well help implementors that come behind us. Russ At 09:45 AM 03/14/2000 -0500, Pawling, John wrote: >Paul (and friends), > >We believe that the "Examples of S/MIME Messages" document should be >enhanced and maintained. We believe that it is extremely valuable to have a >set of properly formatted sample S/MIME messages which can be used to test >S/MIME implementations. We have used the S/MIME Freeware Library (SFL) to >successfully process (i.e. decode, verify, decrypt) the majority of the >samples in the document. I use the term "the majority" because the SFL does >not support every S/MIME v3 optional feature. For example, the SFL does not >support the CMS authenticatedData content type. We have also used the SFL >to construct sample data (such as signed receipts) to be added to the >document. We have automated this SFL testing (through the use or test >drivers and configuration files) so that it can be easily repeated and >modified by us or independently by a third party (we provide all source >code, unencumbered). We are willing to spend time providing sample data to >be included in the Examples document and to provide support when there are >questions regarding the validity of the sample data. We are also willing to >participate in interoperability testing with others. > >We apologize for not providing feedback and submitting sample data sooner. >We have been using the SFL to perform S/MIME v3 interoperability testing >with Microsoft that has exercised the majority of the features specified by >RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS). This testing has included the >RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We were waiting >until we finished interoperability testing with Microsoft to submit the >SFL-produced sample data. Yesterday (3/13/00) we successfully completed RFC >2634 (ESS) signed receipt interoperability testing between the SFL and >Microsoft. This was the last major S/MIME v3 item that needed to be tested >between the SFL and Microsoft. We plan to provide sample signed receipts >for inclusion in the Examples document. We have also performed limited >S/MIME v3 testing with Baltimore and Entrust. > >We still need to perform countersignature interoperability testing. We plan >to pursue this testing with Microsoft. If anybody else can process >countersignatures, please let us know. We are not going to wait until this >testing is done before submitting SFL-produced sample data for inclusion in >the Examples document. > >As many of you know, Jim Schaad created a detailed set of matrices to >document the interoperabilty testing performed between various >implementations. There is a matrix for each S/MIME v3 specification. These >matrices are much more detailed than the "Examples of S/MIME Messages" >document. We have verified that the SFL can produce and process the >majority of the features documented in the compliance matrices. Again, I >use the term "the majority" because the SFL does not support every S/MIME v3 >optional feature. We have automated this SFL testing so that it can be >easily repeated and modified by us or independently by a third party. We >have developed sample objects that illustrate each feature in the matrix >that the SFL supports. > >Please note that Jim Schaad's matrices are a superset of the Examples >document. Does the group want to include all of Jim's tests in the Examples >document? If so, we can provide the sample data to illustrate each feature >in the matrix that the SFL supports. Please note that this document would >be huge, but it would provide a comprehensive set of test data. What do >others think? > >We will have the SFL-produced test data ready for distribution by 24 March >2000 at the latest. > >============================================ >John Pawling, Director - Systems Engineering >J.G. Van Dyke & Associates, Inc; >a Wang Government Services Company >john.pawling@wang.com >============================================ > From owner-ietf-smime Thu Mar 16 00:41:01 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA20381 for ietf-smime-bks; Thu, 16 Mar 2000 00:41:01 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA20377 for ; Thu, 16 Mar 2000 00:41:00 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Mar 2000 00:38:22 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 00:38:22 -0800 Message-ID: From: =?utf-8?B?Q2FtZXJvbiBTdGlsbGlvbg==?= To: =?utf-8?B?J2lldGYtc21pbWVAaW1jLm9yZyc=?= Cc: =?utf-8?B?J3Bob2ZmbWFuQGltYy5vcmcn?= , =?utf-8?B?QnJ5YW4gU3RhYXRz?= Subject: =?utf-8?B?RVNTIDogU2VjdXJlIFJlY2VpcHQgZW5jb2Rpbmcgd2l0aGluIEVu?= =?utf-8?B?Y2Fwc3VsYXRlZENvbnRlbnRJbmZv?= Date: Thu, 9 Mar 2000 18:15:23 -0800 X-MS-TNEF-Correlator: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8F22.FC7C8624" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF8F22.FC7C8624 Content-Type: text/plain; charset="utf-8" ... and now for something completely different: According to the ESS RFC on page 16, step 9: 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. Should eContent be a DER-encoding of the receipt? or Should eContent be a DER-encoding of an OCTET STRING containing the DER-encoding of the receipt? The word "directly" seems to indicate that the former is the correct one. Just tell me I'm not crazy. Cameron Stillion ------_=_NextPart_000_01BF8F22.FC7C8624 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhcIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEFgAMADgAAANAHAwAJABIA DwAXAAQAHwEBCYABACEAAAA1RjJBNEIwNjhCRjVEMzExOUIzMjAwODA1RkQ0NTlGRQAsBwEggAMA DgAAANAHAwAQAAAAJgAVAAQAKQEBDYAEAAIAAAACAAIAAQOQBgDMDgAAOgAAAAsAAgABAAAAAgEx AAEAAABGAAAAAAAAAEyiHl/8uc8RmUsAAAAAAAEHAC79ARQFJM8RmRAAqgBsgNEAAAC+0DMAAORv LnS/xM8RmosAgF/MqycAAAjOXX8AAAAAQAA5AHA6yX02ir8BHwAxQAEAAAASAAAAQwBBAE0ARQBS AE8AUwBUAAAAAAADABpAAAAAAB8AMEABAAAAEgAAAEMAQQBNAEUAUgBPAFMAVAAAAAAAAwAZQAAA AAAfAEsAAQAAAAIAAAAAAAAAHwBwAAEAAAB6AAAARQBTAFMAIAA6ACAAUwBlAGMAdQByAGUAIABS AGUAYwBlAGkAcAB0ACAAZQBuAGMAbwBkAGkAbgBnACAAdwBpAHQAaABpAG4AIABFAG4AYwBhAHAA cwB1AGwAYQB0AGUAZABDAG8AbgB0AGUAbgB0AEkAbgBmAG8AAAAAAAIBcQABAAAAFgAAAAG/igJB XPhvcFf1zBHThDoAYLDsDf8AAAIBCRABAAAARQYAAEEGAAB3GwAATFpGdeotMT4DAAoAcmNwZzEy NYIyA0NodG1sMQMwPwEDAfcKgAKkA+MCAGNowQrAc2V0MCAHEwKA/xADAFAEVghVB7IR1Q5RAwHd ENcyBgAGwxHVMwRGENn5Eu9mNBBvEXYR4wjvCfe2Oxq/DjA1EdIMYGMAUDMLCQFkMzYRYAulNCBZ EAIqXA6yAZBnH2AzACA8IURPQ1RZAFBFIEhUTUwgAFBVQkxJQyAiQC0vL1czQyIgRCRURCE0NC4R YFRyOQBydGkCIAdAIiBFTnwiPhHjH9cggAqjJIwxPjkgkCFCJH4fcCbgRUG+RCR9DvElnymPJmQ2 DvDAPE1FVEEgBaACMLEJ8HQ9IgXgIUM1IzAQMC4yOSawLjYzMDA3IiAj8AeAPUeBJEBFUkFUT1Ik fXo0LFEvKG8gQSr/IDE1wRFgPEJPRFkkfR7hETJfZzk2IJBESVb3JHAf4wAhIAAANtURYB+5nDY0 Nr83wiXsNDggkMBGT05UIGYA0C8AvwcTNqsYMAMwOZ8gEzgoMXBTUEFOLMALYAQQPbEe0Dk1MzNw JrAtP6C8MDMB0C3wNq83sy5CEOogAHBkLsBvB+ACEAXA1nMDcBFAaAuAZx+MPREbNRMFoG0LUBFA ZWx5tCBkBpBmBJAtETo1bL8U8DDQPuJAuUDHOg41NkH+LztCR783vgHAQMcKokho+wqAJewwKDEi gDaLSG80f/81jzafS484v1CvOt877zz//z4PPx9AL1Y/Ro9Hn16fSb+DYK9avyZuYnNwAoDxXcdc J2EBQFRvTG9Nf/9Oj0+fZD9Rv1LPXe9U729v/1cPWB9ZL3IfW09cX11vb/ecQWMFoUWwQ4F0b3sg IGhlIEVTBfBSRt8h4AIgQ69tkwqwZ3uALDDGLEMALQBwIDlGT2AP/2vvYi+AD2cvaD9pT2pfgw// bH9tj26fb69wv3HPct9z7/90/48fdx94L4vvks9/b4hv/4GPgp+Zj2UfZi+D/4UPhh//hy+bz4lP il+Lb4x/jY+Wj/+Pr5C/kc+qv5PvlP+pr6iSPy5QnO+d/58KI1B7cUFT9E4uDvBEL1B8T6XjCfDX BaABAEJwUgWQZQUiLNXpBdBVU6xAYnuARbAawPxjdEWBuCYD8ENSe1MAkORnbgmARGEBkLbPt9bM YXAIUCzzSW4CELqgHb41ICDRLJAGAFRSSXxOR0WgARALgLhxu3Fb+kMF4F2y/JgvpA+aT5tf/6hf oF+hb6J/xZ/D36Wvpr//sd+o387/sw+0H58Px0/IX//Jb8p/0Z/Mn82v0N/Pz9zP/9nvq8+s363v rv+wD7Ef3Vr0U2gIYGxCcL73ufG8f9vbFLaRLbgjQ3Jv3UB7Yvu6QbjSP8Fvwn/jT8Sf7f//1M/V 39bv1//w/9of2y/cP//dT95f32/gf+GP4p/9D+S//+XP+/8Av9L/1A4FPwZPB1//CG8Jf7V26X/4 QkLg7I/tn/8KX++/EM/x3/Lv8//1DxPP//cv+D/5T/pf+28Eb/2P/p///68f3wHPAt8ez+fv6P/q D+/rGUJQv3y5ImHA0HrztgH/6s+2ASlfGxLsDw/vGO8SD/8THxQvFT8WTxdfGG8y3xqP/xufJr8d vz3/Ox8g7yH/Iw//JB8lLyY/QK8w/zn/SQ80L/9LHwsPDB/UXzafN684vznP/05vO+88/0gfPx9Z n0vvQk9/Q19Eb0V/Ro9Hn1xJtfJ3KXrBICK6JiJ+IGVl/G1zLs9X43sxwNB64L4AH7lQe1G8UHtT vsBybWV9WABpZmB7YnqxukJ8EWVnsv9P77UcSnV+MHsgZQhsbCBpUCBJJ204IG5vuYBmj1fyY3L4 YXp5wV9KX1Y/TH9yH/9Rf1KPU59Ur3UfVs9X31jv/1n/Ww9cH10vXj9fT4EvYW//Yn99/4TfcX96 f3OfdK+Ln/9rT2xfdg93H3gveT+N33tf/3xvfX9+j3+fiJ+Bv4LPg9+fnM+F/4cPm7+aokNhaVFH aoBu/5fzU3RpbiBp/2qAiW+Kf6AfjJ+ov5Gfkq//k7+Uz6u/lu+X/5kPmh+bL/+cP48/kE+1b61v rn+vj7CfCbe/ZzWd8S9CT0QmWZ8QsfsyN75BSFRUTUzBbTOy1X3EYAAAAAIBFDoBAAAAEAAAAF8q SwaL9dMRmzIAgF/UWf4DAN4/6f0AAAMAJgAAAAAAAwA2AAAAAAADAPE/CQQAAAMA/T/kBAAAAwAC WQAAFgADAAlZAwAAAAMAAW4gAgAACwAFgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAACA CCAGAAAAAADAAAAAAAAARgAAAABShQAAHm4BAB8AAYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB AAAACAAAADkALgAwAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAG gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAiACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAHwAOgAggBgAAAAAAwAAAAAAAAEYA AAAAg4UAAAEAAAAmAAAANgAwADkANQAzADUAMAAxADkALQAwADkAMAAzADIAMAAwADAAAAAAAAMA gBD/////CwDyEAEAAAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAAAfAPMQAQAAAIYAAABFAFMAUwAg ACUAMwBBACAAUwBlAGMAdQByAGUAIABSAGUAYwBlAGkAcAB0ACAAZQBuAGMAbwBkAGkAbgBnACAA dwBpAHQAaABpAG4AIABFAG4AYwBhAHAAcwB1AGwAYQB0AGUAZABDAG8AbgB0AGUAbgB0AEkAbgBm AG8ALgBFAE0ATAAAAAAAAgFHAAEAAAAyAAAAYz1VUzthPSA7cD1NaWNyb3NvZnQ7bD1SRU5DSE9X LTAwMDMxMDAyMTUyM1otMTA3OQAAAAIB+T8BAAAATQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAA AAAAAAAvTz1NSUNST1NPRlQvT1U9T0ZGSUNFL0NOPVJFQ0lQSUVOVFMvQ049Q0FNRVJPU1QAAAAA HwD4PwEAAAA4AAAAQwBhAG0AZQByAG8AbgAgAFMAdABpAGwAbABpAG8AbgAgACgARQB4AGMAaABh AG4AZwBlACkAAAAfADhAAQAAABIAAABDAEEATQBFAFIATwBTAFQAAAAAAAIB+z8BAAAATQAAAAAA AADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1NSUNST1NPRlQvT1U9T0ZGSUNFL0NOPVJFQ0lQ SUVOVFMvQ049Q0FNRVJPU1QAAAAAHwD6PwEAAAA4AAAAQwBhAG0AZQByAG8AbgAgAFMAdABpAGwA bABpAG8AbgAgACgARQB4AGMAaABhAG4AZwBlACkAAAAfADlAAQAAABIAAABDAEEATQBFAFIATwBT AFQAAAAAAEAABzDQM2Z5Noq/AUAACDAkhnz8Io+/AR8AGgABAAAAEgAAAEkAUABNAC4ATgBPAFQA RQAAAAAAHwA3AAEAAAB6AAAARQBTAFMAIAA6ACAAUwBlAGMAdQByAGUAIABSAGUAYwBlAGkAcAB0 ACAAZQBuAGMAbwBkAGkAbgBnACAAdwBpAHQAaABpAG4AIABFAG4AYwBhAHAAcwB1AGwAYQB0AGUA ZABDAG8AbgB0AGUAbgB0AEkAbgBmAG8AAAAAAB8APQABAAAAAgAAAAAAAAAfAB0OAQAAAHoAAABF AFMAUwAgADoAIABTAGUAYwB1AHIAZQAgAFIAZQBjAGUAaQBwAHQAIABlAG4AYwBvAGQAaQBuAGcA IAB3AGkAdABoAGkAbgAgAEUAbgBjAGEAcABzAHUAbABhAHQAZQBkAEMAbwBuAHQAZQBuAHQASQBu AGYAbwAAAAAAHwA1EAEAAABmAAAAPABFADQANgBGADIARQA3ADQAQgBGAEMANABDAEYAMQAxADkA QQA4AEIAMAAwADgAMAA1AEYAQwBDAEEAQgAyADcAMAA4AEQAQwA3ADMARQAyAEAAUgBFAE4AQwBI AE8AVwA+AAAAAAALACkAAAAAAAsAIwAAAAAAAwAGEMu/X3MDAAcQnQEAAAMAEBADAAAAAwAREAAA AAAeAAgQAQAAAGUAAABBTkROT1dGT1JTT01FVEhJTkdDT01QTEVURUxZRElGRkVSRU5UOkFDQ09S RElOR1RPVEhFRVNTUkZDT05QQUdFMTYsU1RFUDk6OVRIRUFTTjFERVJFTkNPREVEUkVDRUlQVENP AAAAAAIBfwABAAAAMwAAADxFNDZGMkU3NEJGQzRDRjExOUE4QjAwODA1RkNDQUIyNzA4REM3M0Uy QFJFTkNIT1c+AABkEQ== ------_=_NextPart_000_01BF8F22.FC7C8624-- From owner-ietf-smime Thu Mar 16 04:00:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA02297 for ietf-smime-bks; Thu, 16 Mar 2000 04:00:33 -0800 (PST) Received: from mailserver.ipf.net (smtp.itl-online.de [195.211.211.86]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA02292 for ; Thu, 16 Mar 2000 04:00:31 -0800 (PST) Message-Id: <200003161200.EAA02292@ns.secondary.com> Received: (qmail 21084 invoked from network); 16 Mar 2000 11:52:23 -0000 Received: from dialin-194-29-49-241.hannover.gigabell.net (HELO localhost) (194.29.49.241) by mail.okay.net with SMTP; 16 Mar 2000 11:52:23 -0000 From: "Alexander" To: "A good opportunity for u" Date: Thu, 16 Mar 2000 12:51:29 +0100 Subject: Surfingprize brand new Get-paid-programm (very good) Reply-To: Eugen@okay.net MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SurfingPrizes: A viewBar type that: The referral structure is 5 levels deep: For your surfing time, you'll receive $0.20 per hour; for your direct referrals, you'll earn $0.04/hour; and for your indirect referrals you'll earn $0.02/hour. For 5 levels deep! ViewBar Ver 1.0 Avalible for Win 95,98,NT Site is well laid out and snappy. I'm only number 786 in this one. Sign-up Here: http://www.surfingprizes.com/r/?100786 Thanks for sign-up under me Alexander Eugen@okay.net From owner-ietf-smime Thu Mar 16 10:40:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA15767 for ietf-smime-bks; Thu, 16 Mar 2000 10:40:30 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15762; Thu, 16 Mar 2000 10:40:27 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 13:41:22 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF31965BC2@wfhqex01.wangfed.com> From: =?UTF-8?B?UGF3bGluZywgSm9obg==?= To: =?UTF-8?B?J0NhbWVyb24gU3RpbGxpb24n?= , =?UTF-8?B?J2lldGYtc21pbWVAaW1jLm9yZyc=?= Cc: =?UTF-8?B?J3Bob2ZmbWFuQGltYy5vcmcn?= , =?UTF-8?B?QnJ5YW4gU3RhYXRz?= Subject: =?UTF-8?B?UkU6IEVTUyA6IFNlY3VyZSBSZWNlaXB0IGVuY29kaW5nIHdpdGhp?= =?UTF-8?B?biBFbmNhcHN1bGF0ZWRDb250ZW50SW5mbw==?= Date: Thu, 16 Mar 2000 13:41:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="UTF-8" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cameron, The signedData encapContentInfo eContent field is defined as an OCTET STRING in RFC 2630 (CMS). If the eContent field is present, then the OCTET STRING tag and length octets must be present in the encoding of the signedData. RFC 2630 Section 2 states: "As a general design philosophy, each content type permits single pass processing using indefinite-length Basic Encoding Rules (BER) encoding." and "Signed attributes and authenticated attributes are the only CMS data types that require DER encoding." Therefore, the signedData content type (including the encapContentInfo eContent OCTET STRING tag and length octets) does not need to be DER-encoded. As you correctly point out, RFC 2634 (ESS) requires that the Receipt content type must be DER-encoded within the signedData encapContentInfo eContent OCTET STRING. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ -----Original Message----- From: Cameron Stillion [ mailto:camerost@EXCHANGE.MICROSOFT.com ] Sent: Thursday, March 09, 2000 9:15 PM To: 'ietf-smime@imc.org' Cc: 'phoffman@imc.org'; Bryan Staats Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo ... and now for something completely different: According to the ESS RFC on page 16, step 9: 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. Should eContent be a DER-encoding of the receipt? or Should eContent be a DER-encoding of an OCTET STRING containing the DER-encoding of the receipt? The word "directly" seems to indicate that the former is the correct one. Just tell me I'm not crazy. Cameron Stillion From owner-ietf-smime Fri Mar 17 08:31:03 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA16941 for ietf-smime-bks; Fri, 17 Mar 2000 08:31:03 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16937 for ; Fri, 17 Mar 2000 08:31:02 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 17 Mar 2000 09:31:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 17 Mar 2000 09:31:43 -0700 From: "Bob Jueneman" To: , Cc: Subject: Re: S/MIME v3 Interoperability Testing (was RE: S/MIMEexamples draft ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16938 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It occurs to me that this effort would be extremely useful in trying to further the interoperability testing that the PKI Forum is being set up to do. What would be really great would be if we could go beyond examples, and try to develop actual test cases. Or maybe contribute test cases that we have developed internally. As an example of the kind of obscure things that can bite you, I recently tried to gather up an entire set of encrypted correspondence by sending a encrypted message to myself with 30 or so encrypted attachments that I dragged on to the attachment window. Didn't work. Only one message showed up in the attachments. So there's one bug to more to fix. Why would you want to do such a thing? For compactness and archiving , and perhaps to hide the plaintext headers that show who you were communicating with. Bob >>> Russ Housley 03/15/00 12:06PM >>> John: John, as S/MIME WG chairman, I greatly appreciate your commitment. I hope that other implementors will join in this effort. Collecting this data is essential for the specifications to progress from Proposed Standard to Draft Standard, so we might as well help implementors that come behind us. Russ At 09:45 AM 03/14/2000 -0500, Pawling, John wrote: >Paul (and friends), > >We believe that the "Examples of S/MIME Messages" document should be >enhanced and maintained. We believe that it is extremely valuable to have a >set of properly formatted sample S/MIME messages which can be used to test >S/MIME implementations. We have used the S/MIME Freeware Library (SFL) to >successfully process (i.e. decode, verify, decrypt) the majority of the >samples in the document. I use the term "the majority" because the SFL does >not support every S/MIME v3 optional feature. For example, the SFL does not >support the CMS authenticatedData content type. We have also used the SFL >to construct sample data (such as signed receipts) to be added to the >document. We have automated this SFL testing (through the use or test >drivers and configuration files) so that it can be easily repeated and >modified by us or independently by a third party (we provide all source >code, unencumbered). We are willing to spend time providing sample data to >be included in the Examples document and to provide support when there are >questions regarding the validity of the sample data. We are also willing to >participate in interoperability testing with others. > >We apologize for not providing feedback and submitting sample data sooner. >We have been using the SFL to perform S/MIME v3 interoperability testing >with Microsoft that has exercised the majority of the features specified by >RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS). This testing has included the >RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We were waiting >until we finished interoperability testing with Microsoft to submit the >SFL-produced sample data. Yesterday (3/13/00) we successfully completed RFC >2634 (ESS) signed receipt interoperability testing between the SFL and >Microsoft. This was the last major S/MIME v3 item that needed to be tested >between the SFL and Microsoft. We plan to provide sample signed receipts >for inclusion in the Examples document. We have also performed limited >S/MIME v3 testing with Baltimore and Entrust. > >We still need to perform countersignature interoperability testing. We plan >to pursue this testing with Microsoft. If anybody else can process >countersignatures, please let us know. We are not going to wait until this >testing is done before submitting SFL-produced sample data for inclusion in >the Examples document. > >As many of you know, Jim Schaad created a detailed set of matrices to >document the interoperabilty testing performed between various >implementations. There is a matrix for each S/MIME v3 specification. These >matrices are much more detailed than the "Examples of S/MIME Messages" >document. We have verified that the SFL can produce and process the >majority of the features documented in the compliance matrices. Again, I >use the term "the majority" because the SFL does not support every S/MIME v3 >optional feature. We have automated this SFL testing so that it can be >easily repeated and modified by us or independently by a third party. We >have developed sample objects that illustrate each feature in the matrix >that the SFL supports. > >Please note that Jim Schaad's matrices are a superset of the Examples >document. Does the group want to include all of Jim's tests in the Examples >document? If so, we can provide the sample data to illustrate each feature >in the matrix that the SFL supports. Please note that this document would >be huge, but it would provide a comprehensive set of test data. What do >others think? > >We will have the SFL-produced test data ready for distribution by 24 March >2000 at the latest. > >============================================ >John Pawling, Director - Systems Engineering >J.G. Van Dyke & Associates, Inc; >a Wang Government Services Company >john.pawling@wang.com >============================================ > From owner-ietf-smime Wed Mar 22 18:08:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA02547 for ietf-smime-bks; Wed, 22 Mar 2000 18:08:08 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02540 for ; Wed, 22 Mar 2000 18:08:07 -0800 (PST) Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id SAA15724; Wed, 22 Mar 2000 18:09:25 -0800 (PST) Message-Id: <4.2.0.58.20000321103332.00a4c580@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 21 Mar 2000 11:18:41 -0500 To: Weston.Nicolls@ey.com From: Russ Housley Subject: draft-ietf-smime-seclabel-00.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Weston: I have two questions about the Internet-Draft. QUESTION 1. The Amoco policy defines confidentiality hierarchy and an integrity hierarchy. In practice, is a piece of information marked with a confidentiality value, an integrity value, or both? The ASN.1 defined in the document leads me to believe that a particular piece of information has either a confidentiality value or an integrity value, but never both. You included the following ASN.1: Amoco-SecurityClassification ::= { amoco general (6), amoco confidential (7), amoco highly confidential (8), amoco minimum (9), amoco medium (10), amoco maximum (11) } Since the classification in the ESS security label is a single INTEGER, only one of these values may be present in a particular instance of a security label. Is the integrity value ever used to make an access control decision? If not, then perhaps the integrity value should be carried in the privacy mark. QUESTION 2. In the Whirlpool section, you say: For WHIRLPOOL INTERNAL, additional markings or caveats are option at the discretion of the information owner. For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to comply with regulatory or heightened security requirements. Examples: MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT. The examples listed can be characterized as guidance to the information recipient about how the needs to be handled. Mostly, guidance is provided about the redistribution of the information. Since these are examples, I wonder if there is a example of a caveat on which one might expect automated access control. Russ From owner-ietf-smime Thu Mar 23 11:33:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA15606 for ietf-smime-bks; Thu, 23 Mar 2000 11:33:20 -0800 (PST) Received: from inet-smtp3.oracle.com (inet-smtp3.us.oracle.com [205.227.43.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15602 for ; Thu, 23 Mar 2000 11:33:19 -0800 (PST) Received: from mailsun3.us.oracle.com (mailsun3.us.oracle.com [130.35.62.244]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id LAA28332; Thu, 23 Mar 2000 11:35:17 -0800 (PST) Received: from us.oracle.com by mailsun3.us.oracle.com with ESMTP (8.8.8+Sun/37.9) id LAA25741; Thu, 23 Mar 2000 11:35:17 -0800 (PST) Message-ID: <38DA73CA.4A3F1648@us.oracle.com> Date: Thu, 23 Mar 2000 11:43:06 -0800 From: Guang Yee X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pawling, John" CC: "'SMIME WG'" Subject: Re: v1.5 SFL Freely Available to All!! References: <33BD629222C0D211B6DB0060085ACF31965980@wfhqex03.wang.com> Content-Type: multipart/mixed; boundary="------------8B518FEC5C6CAE5D1E8289D6" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8B518FEC5C6CAE5D1E8289D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, Is SFL v1.5 currently available on HP? If not, when will SFL v1.5 be ported to HP? Thanks, Guang "Pawling, John" wrote: > All, > > J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has > delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and > Application Programming Interface (API). The SFL source code files are > freely available to everyone from the Fortezza Developer's S/MIME Page > (with no password > control). On 14 January 2000, the U.S. Department of Commerce, Bureau of > Export Administration published a new regulation implementing an update to > the U.S. Government's encryption export policy > . In accordance with the > revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, > the downloading of the SFL source code is no longer password controlled. > > The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message > Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. > It also implements portions of the RFC 2633 Message Specification and > RFC 2632 Certificate Handling document. When used in conjunction with > the Crypto++ freeware library, the SFL implements the RFC 2631 > Diffie-Hellman (D-H) Key Agreement Method specification. It has been > successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating > systems. Further enhancements, ports and testing of the SFL are still in > process. Further releases of the SFL will be provided as significant > capabilities are added. > > The SFL has been successfully used to sign, verify, encrypt and decrypt > CMS/ESS > objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H, > 3DES) > provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by > the > RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms > provided by the Fortezza Crypto Card. The SFL uses the VDA-enhanced SNACC > v1.3 > ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL > High- > level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); > > BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); > VDA- > enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities; > > test drivers and test data. All CTILs were tested as Dynamically Linked > Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs > were > tested with the respective security libraries as shared objects using > Solaris 2.7. > > The SFL has been successfully used to exchange signedData and envelopedData > messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and > > Netscape Communicator 4.X S/MIME v2 products. Signed messages have been > exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. > > The SFL has also been used to perform S/MIME v3 interoperability testing > with > Microsoft that exercised the majority of the features specified by RFCs > 2630, > 2631 and 2634. This testing included the RSA, mandatory S/MIME V3 and > Fortezza > suites of algorithms. We have also performed limited S/MIME v3 testing with > > Baltimore and Entrust. We are also participating in the IETF S/MIME WG > interoperability testing documented in the "Examples of S/MIME Messages" > document. We have used the SFL to successfully process all of the correct > signedData and envelopedData messages included in the document. We are > continuing to set up test config files to use the SFL to test the other > cases > included in the document such as signed receipts. We also plan to provide > sample messages for inclusion in the document. > > The following enhancements are included in the v1.5 SFL release (compared > with > the v1.4 release): > > 1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly > processed. > > 2) Fixed many memory leaks; > > 3) Full CounterSignature test suite (autohiAllSFLd.cfg); > > 4) CertificateBuilder utility generates private/public key pairs and > certificates (there is a "README.txt" file in the root directory regarding > this > utility). > > 5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS > #11 > crypto library, but this project provides a good template for PKCS #11). We > > are still testing the PKCS #11 CTIL. > > 6) Developed new test code and configuration files to implement test cases; > and > > 7) Performed regression testing to ensure that aforementioned enhancements > did > not break existing SFL functionality. > > We are still in the process of enhancing and testing the SFL. Future > releases > will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL > encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line > utility; modify PKCS #12 code in test utilities to provide interoperable key > > storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode > functions; add enhanced test routines; bug fixes; support for other crypto > APIs > (possible); and support for other operating systems. > > The SFL is developed to maximize portability to 32-bit operating > systems. In addition to testing on MS Windows and Solaris 2.7, we plan to > port > the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 > (possibly), SCO 5.0 (possibly) and Macintosh (possibly). > > The following SFL files are available from the Fortezza Developer's S/MIME > Page: > > 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, > Software Test Description, Implementers Guide, Overview Briefing and Public > License. > > 2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler > and > Library source code compilable for Unix and MS Windows NT/95/98 that has > been > enhanced by VDA to implement the Distinguished Encoding Rules. Project > files > and makefiles are included. This file includes a sample test project > demonstrating the use of the SNACC classes. > > 3) smimeR15.zip: Zip file containing all SFL source code including: > SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source > code; project files. This file also contains test driver source code, > sample CMS/ESS test data and test X.509 Certificates. This file also > includes test utilities to create X.509 Certificates that each include > a D-H, DSA or RSA public key. SNACC release and debug libraries > are compiled for MS Windows NT/95/98. MS Windows NT/95/98 > project files and Unix makefiles are included for the SNACC code and > Crypto++. > > 4) smR15CTI.zip: Source code for the following CTILs: Test (no crypto), > Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11. The Win95/98/NT projects are > > also included. (NOTE: The Free (a.k.a. Crypto++) CTIL includes > VDA-developed > source code to use the RSA public key algorithm implemented within the > external > Crypto++ library. As with all of the external crypto token libraries, the > Crypto++ library is not distributed as part of the SFL source code. > To use the Crypto++ library with the SFL, the application developer must > independently obtain the Crypto++ library from the Crypto++ Web Page > and then compile it with > the VDA-developed Crypto++ CTIL source code. The RSA public key > algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication > System and Method". Within the U.S., users of the RSA public key algorithm > provided by the external Crypto++ library must obtain a license from RSA > granting them permission to use the RSA algorithm.) > > 5) csmime.mdl contains SFL Class diagrams created using Microsoft > Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). > The file can also be viewed using Rational Rose C++ Demo 4.0 > 45 day evaluation copy which can be obtained from > . > Not all classes are documented in the MDL file at this time. > > All source code for the SFL is being provided at no cost and with no > financial limitations regarding its use and distribution. > Organizations can use the SFL without paying any royalties or > licensing fees. VDA is developing the SFL under contract to the U.S. > Government. The U.S. Government is furnishing the SFL source code at no > cost to the vendor subject to the conditions of the "SFL Public > License" available from the VDA SFL Page and Fortezza Developer's > S/MIME Page. > > The SFL is composed of a high-level library that performs generic CMS > and ESS processing independent of the crypto algorithms used to > protect a specific object. The SFL high-level library makes calls to > an algorithm-independent CTIL API. The underlying, external crypto > token libraries are not distributed as part of the SFL > source code. The application developer must independently obtain these > libraries and then link them with the SFL. For example, the SFL uses > the freeware Crypto++ library to obtain 3DES, D-H and DSA. To use > the SFL with Crypto++ the vendor must download the Crypto++ freeware > library from the Crypto++ Web Page and then compile it with the > VDA-developed Crypto++ CTIL source code. > > The Internet Mail Consortium (IMC) has established an SFL web page > . The IMC has also established an SFL > mail list which is used to: distribute information regarding SFL > releases; discuss SFL-related issues; and provide a means for SFL > users to provide feedback, comments, bug reports, etc. Subscription > information for the imc-sfl mailing list is at the IMC web site > listed above. > > The SFL documents and VDA-enhanced SNACC source code are also > available from the VDA SFL Web Page > . > > All comments regarding the SFL source code and documents are welcome. > We recommend that comments should be sent to the imc-sfl mail list. > We will respond to all messages on that list. > > ============================================ > John Pawling, Director - Systems Engineering > J.G. Van Dyke & Associates, Inc; > a Wang Government Services Company > john.pawling@wang.com > ============================================ --------------8B518FEC5C6CAE5D1E8289D6 Content-Type: text/x-vcard; charset=us-ascii; name="gyee.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Guang Yee Content-Disposition: attachment; filename="gyee.vcf" begin:vcard n:Yee;Guang tel;work:(650)633-6338 x-mozilla-html:FALSE url:messaging.us.oracle.com org:Oracle;Email Server version:2.1 email;internet:gyee@us.oracle.com title:Senior Member of Technical Staff adr;quoted-printable:;;600 Oracle Parkway=0D=0AM/S: 6op3;Redwood Shores;CA;94065;U.S.A fn:Guang Yee end:vcard --------------8B518FEC5C6CAE5D1E8289D6-- From owner-ietf-smime Sun Mar 26 11:08:54 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA04882 for ietf-smime-bks; Sun, 26 Mar 2000 11:08:54 -0800 (PST) Received: from mail.harrassowitz.de (intergw.harrassowitz.de [193.97.189.19]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA04878 for ; Sun, 26 Mar 2000 11:08:51 -0800 (PST) Message-Id: <0003261735.AA17824@mail.harrassowitz.de> Received: from cranston-ip-2-123.dynamic.ziplink.net by mail.harrassowitz.de with SMTP (AIX 4.1/UCB 5.64/GEN-1.2.0) via EUnet for mail.proper.com id AA17824; Sun, 26 Mar 2000 19:35:02 +0200 From: "Owen" Subject: Get Ready For Some Mail That You Like To: see39s@harrassowitz.de X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 26 Mar 2000 14:37:15 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA04879 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Perhaps this might be of interest to you. HERE IS YOUR REQUESTED INFORMATION!: Fellow entrepreneur: Don't knock it until you at least read this. For the first time ever, I have received a piece of email that actually delivered more than just empty promises! 5LIST! = $$$$$ IN THE BANK! Perhaps this might be of interest to you? GET PAID $5 PER SIGNUP TO BUILD YOUR OWN MAIL LIST! .......why do it for free?? (Example: you get 10 they get 10ea.=100 they get 10 ea.=1000 WOW!~Each sending $5 to you=WOW!) If you need to make a few thousand dollars REALLY FAST, then please, take a moment to read this simple program I am sharing with you. You DO NOT have to send $5 to five people, buy their reports, or recipes, or anything like that. Nor will you have to invest more money later to get things going. THIS IS THE FASTEST, EASIEST PROGRAM YOU WILL EVER DO. Complete it in one hour, and you will never forget the day you first received it. The following is a plan to benefit you and your future. $$$$$ BE PREPARED TO GET EXCITED...YOU WON'T BE DISAPPOINTED!!! Read the following and you will agree this is a very exciting opportunity. Only invest a little bit of time, and your reward could mean thousands of dollars! Good luck! ********************************************************************* ************ “IT'S OUTRAGEOUS!!! With two hours of work I have made over US $11,000 In the last three weeks…..and my investment was just $5!!! I LOVE IT! Thank you 11,000 x's!” -Julie M. St. Louis ********************************************************************* *********** ARE YOU IN NEED OF MONEY RIGHT NOW? HOW DOES $10,000 IN TWO WEEKS SOUND? Don't laugh! Try this, for a change, while you wait for the others to start working. One hour of work to get started and no mailing lists! ********************************************************************* ****** Esquire Marketing Newsletter Gift Club. This service is 100% legal (Refer to US Postal and Lottery Laws, Title18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state "a product or service must be exchanged for money received") ********************************************************************* ********** Here's How It Works: Unlike many other programs, this three level program is more realistic and much, much faster. Because it is so easy, the response rate for this program is VERY HIGH AND VERY FAST, and you will see results in two weeks or less! Just in time for next month's bills! You only mail out 20 copies (not 200 or more as in other programs). You should also send them to people who send you their programs, because they know these programs work and they are already believers in the system! Besides, this program is MUCH, MUCH FASTER and has a HIGHER RESPONSE RATE! Even if you are already in a program, stay with it, but do yourself a favor and DO THIS ONE as well. START RIGHT NOW! It's simple and takes a very small investment. It will pay off long before other letters even begin to trickle in! $$$$$ Just give ONE person a $5 gift. That's all! $$$$$ Follow the simple instructions and in two weeks you will have US$10,0 00 in your bank account! Because of the LOW INVESTMENT, SPEED, and HIGH PROFIT POTENTIAL, this program has a VERY HIGH RESPONSE RATE! Just one (1) US $5 bill. That's your investment!!! ********************************************************************* ********** Follow These Simple Instructions: 1) On a blank sheet of paper write "Please add me to your mailing list." Write your name and address clearly and include your email address for future mailings and courtesy follow ups. Fold it around a US $5 and send it to the FIRST name on the list (#1) . Only the first person on the list gets your name and a five dollar gift. 2) Retype only the list, removing the FIRST (#1) NAME FROM THE LIST . Move the other two names UP and ADD YOUR NAME to the list in the THIRD (#3) position. 3) Send out 20 copies of this letter. NOTE: by sending this letter via EMAIL, The response time is much faster, and you save the expenses of envelopes,stamps, and copying services Consider this; MILLIONS of people "surf the Internet"everyday, all day, all over the world! Fifty thousand new people get on the Internet every month! An excellent source of names are the people who send you other programs and the names listed onthe letter they send you. Your contact source is UNLIMITED! It boggles my mind to think of all the possibilities! Mail, or should I say Email, your letter TODAY! It's so easy. One hour of your time. THAT'S IT! To send your newsletter by Email: 1) Go to "edit" and "select all" 2) Go to "edit" and "copy" 3) Start (compose) a new Email message 4) Address your Email and Subject blocks 5) Go to "edit" and "paste". After you have pasted this article to your new Email, delete the old header and footer (Subject, Date, To, From, Etc.) Now you can edit the names and addresses with ease. I recommend deleting the top name, adding your name and address to the bottom of the list, then simply changing the numbers. THERE'S NOTHING MORE TO DO. When your name reaches the first position in a few days, it will be your turn to collect your gifts. The gifts will be sent to you by 1,500 to 2,000 people like yourself, who are willing to invest US $5 and one hour to receive US $10,000 in cash. That's all! There will be a total of US$10,000 in US$5 bills in your mailbox in two weeks. US$10,000 for one hour’s work! I think it's WORTH IT, don't you? GO AHEAD...TRY IT. IT'S US$5!... EVEN IF YOU MAKE JUST 3 OR 4 THOUSAND, WOULDN'T THAT BE NICE? IF YOU TRY IT, IT WILL PAY! ********************************************************************* *********** TRUE STORY Cindy Allen writes: “I ran this gift summation four times last year. The first time I received over $7,000 in cash in less than two weeks and over $10,000 in cash in the next three times I ran it. I can't begin to tell you how great it feels Not to have to worry about money anymore! I thank God for the day I received this letter! It has truly changed my life! Don't be afraid to make gifts to strangers, they'll come back to you in ten-fold. So, let's keep it going and help each other out in these "tough and uncertain times." ********************************************************************* *********** CAN I DO IT AGAIN? OF COURSE YOU CAN this plan is structured for everyone to send only 20 letters each. However, you are certainly not limited to 20. Mail out as many as you can. Every 20 letters you send has a return of $10,000 or more. If you can mail forty, sixty, eighty, or whatever, GO FOR IT! THE MORE YOU PUT INTO IT, THE MORE YOU GET OUT OF IT Each time you run this program, just follow steps 1 thru 3 and everyone on your gift list benefits! Simple enough? You bet it is! Besides, there are no mailing lists to buy,(and wait for), and trips to the printer or copier, and you can do it again and again, with your regular groups or gifters, or start up a new group. Why not? It beats working! Each time you receive an MLM offer, Respond with this letter! Your name will climb to the number one position at dizzying rates Follow the simple instructions, and above all, PLEASE PLAY FAIR. That's the key to this program’s success. Your name must run the full gamut on the list to produce the end results. Sneaking your name higher up on the list WILL NOT produce the results as you think, and it only cheats the other people who have worked hard and have earned the right to be there. So please, play by the rules and the $$$ will come to you! ********************************************************************* *********** MAIL YOUR LETTERS OUT TODAY! $$$ Together we will prosper! $$$ GOOD LUCK!!! ********************************************************************* ************ 1. Bonnie Mallalieu MC Box 5179 Clinton, MS 39058 2. FWM Marketing 1602 N Maryland Ave Plant City, Fl 33556 3. Paul D. Gram 16277 NW 20th St Pembroke Pines, Fl. 33028 ********************************************************************* ********** Wishing you the best in all you do! You probably don't believe this will work, but if you don't try it, you will never know. That's the way I felt. Try it. You won't be sorry. Paul Gram For support and to Maximize your success Email me with "5list"in subject heading along with a copy of your re-done list ********************************************************************* ************ IMPORTANT: This is a one and only email, if you do not join, if you are not interested or even if you are interested, you will not get any more email regarding this from me. It is up to you now. ********************************************************************* *********** WISHING YOU THE BEST LIFE HAS TO OFFER! ********************************************************************* *************** Please Remove at: mailto:george4343@yahoo.com?subject=remove ********************************************************************* *************** From owner-ietf-smime Sun Mar 26 16:24:21 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA09139 for ietf-smime-bks; Sun, 26 Mar 2000 16:24:21 -0800 (PST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09135 for ; Sun, 26 Mar 2000 16:24:17 -0800 (PST) Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id JAA31448 return ; Mon, 27 Mar 2000 09:56:11 +0930 (CST) From: "Jim Schaad" To: "Cameron Stillion" , Cc: "Bryan Staats" Subject: RE: ESS : Secure Receipt encoding within EncapsulatedContentInfo Date: Mon, 27 Mar 2000 09:55:42 +0930 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01BF97D2.9CF82E20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-MS-TNEF-Correlator: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BF97D2.9CF82E20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just to be a little more clare abouit this. My response would be as follows: 1. It is stated that the reciept must be DER encoded. 2. The directly statement is made with respect to the lack of a MIME = layer being inserted between the receipt content and the surrounding = SignedData ASN construct (i.e. the MIME layer is omitted unlike what is done in wrapping a signed message in an encrypted message). 3. The OCTET wrapping or lack of is addressed by either PKCS#7 or CMS drafts. It is present for CMS and omitted for PKCS#7. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Cameron Stillion Sent: Friday, March 10, 2000 11:45 AM To: 'ietf-smime@imc.org' Cc: 'phoffman@imc.org'; Bryan Staats Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo ... and now for something completely different: =20 According to the ESS RFC on page 16, step 9: =20 9. The ASN.1 DER encoded Receipt content MUST be directly encoded = within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. Should eContent be a DER-encoding of the receipt? or Should eContent be a DER-encoding of an OCTET STRING containing the DER-encoding of the receipt? =20 The word "directly" seems to indicate that the former is the correct = one. Just tell me I'm not crazy. =20 Cameron Stillion ------=_NextPart_000_0004_01BF97D2.9CF82E20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IioAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHAwAbAAkANQAAAAEANAEB A5AGAGgJAAApAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAIBMQAB AAAARgAAAAAAAABMoh5f/LnPEZlLAAAAAAABBwAu/QEUBSTPEZkQAKoAbIDRAAAAvtAzAADkby50 v8TPEZqLAIBfzKsnAAAIzl1/AAAAAAMANgAAAAAAHgBwAAEAAAA9AAAARVNTIDogU2VjdXJlIFJl Y2VpcHQgZW5jb2Rpbmcgd2l0aGluIEVuY2Fwc3VsYXRlZENvbnRlbnRJbmZvAAAAAAIBcQABAAAA GwAAAAG/igJBXPhvcFf1zBHThDoAYLDsDf8DX0OOIAACAR0MAQAAABcAAABTTVRQOkpJTVNDSEBO V0xJTksuQ09NAAALAAEOAAAAAEAABg4ACn+bgpe/AQIBCg4BAAAAGAAAAAAAAADGH5V+7uPTEZY8 AACGM1pkwoAAAAsAHw4BAAAAAgEJEAEAAABKBAAARgQAAOQGAABMWkZ1x40WzgMACgByY3BnMTI1 4jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMR JfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSgR1cwVAdG8gYmWgIGEg bGkCQGwdgPMEYBggIGMLYB5RAaAIYEsd0B0waAQALiAF0HkyIBggc3ACIBQQIHe5CGBsZB1jBCAC EGwXsLh3czoKogqECoAxH5HWSQVABAAgHRBhDrAgwN8fUCNAH0EdgBggYwiQBTGGbR0CHXFERVIg CfBTBaABAGQuIcQyH5FU+SPxZGkkIR3wH9AjIweAvwIwIuIAwAEAIHAd0Ggf4w8m8R0yI+ILYGNr IG9CZh2RTUlNRSmhefcSgR1wC4BnIuAgQQAgI2H5HXB0dwnhI9YrEAUxBaDfAjAnsgBwI3IdgHMI cANghnUtwCsiU2lnbgmAxkQjQB2gQVNOLSIdEIZyGtAFQChpLmUfkP8j4ipZIvEDcB3RI2EugB3A 7msgYSOiIvFkAiAdgAuA4SBwcmFwcCsiHaAAkMcvEh4gB5BzYWczowORWSVhcnkFMDToKSXVM8Em VU9DVEVUM+gFsfcptiLxKDBkH/EUECDBH9AHKxAj4QXAUEtDUyPaNzjiQwXhOfBhAYAfgv0ixHAf 8SeyAhA7lC2yMgZvPWI7FCXVIcRqB3Ahyi31QQJPBRBnC4AHQAXQNSSrQQMhxEYDYTop8HcvIMxy LQiQADAtczIQB4CWQADAAxAuB3BjLgWwbStAW0RyHUA6Q29Eel1STwOgQmUT4GwqEE85KhBDYQeA A2ADoFN0/wMQHcACICHEBmACMENAQwB0aWQqsCwF0ArAE9AgPDEwSpAB0EtgSwAxOlQ0NRDATSHE VEWgIJYnRilExSchxENjTKG8cGgqAARQAHBNdztHwFc2IAORSPBhI0BzSXV1zGJqJvFDQEVTBfBD QO0GYGMIcB2AUizFJWMrIvsocjPBRSVwNBAuMAtgI1FzCFAtU0luAhAhyiHELttWcC2jbiGAPVNz A3AUILdToStABaBtC1AUIGUnIX8mwAEgBJBJ4iHECuMKgEEeYwWhLqMpRVGSUkZDzynwA6AKsDVh MTZKkB0QaSRgIDlZXDkmVS+hLo4xJRpSVy02TVVTOED/HXEmx17mU3Ut8y8IJWE0EB9UqSVQVKU3 9WCAUklOvkcmsAEQC4AjYTPBWzux+l0/S1NOwCCiZGcdcyUh7i1S5yoBLHk/WWVrAQWw/2c/aE9p VwORZPstMgtxWpN/I/Fo72n/WcUmgiCACyAg2iImxiIjEAngbQQgHUH/C4AmwFQADrAjiD1hSJEi 4v8j4gWhJuJbsTCxHOVYgAMgcweAIrAnbVbhLRE0AHpeeSXVWcVIfyHTfXswAAAeAEIQAQAAADMA AAA8RTQ2RjJFNzRCRkM0Q0YxMTlBOEIwMDgwNUZDQ0FCMjcwOERDNzNFMkBSRU5DSE9XPgAAAwAA gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAABShQAA J2oBAB4ABIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAAWACCAGAAAAAADA AAAAAAAARgAAAAAGhQAAAAAAAAMABoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAHgAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALAAiACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMACYAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAA AAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAADiF AAABAAAAAQAAAAAAAAAeABCACCAGAAAAAADAAAAAAAAARgAAAACDhQAAAQAAABMAAAAyMDAyNDU5 MjMtMjYwMzIwMDAAAAsAFoAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAgH4DwEAAAAQAAAA xh+Vfu7j0xGWPAAAhjNaZAIB+g8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQCAfsPAQAAAE0AAAAA AAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABD OlxtYWlsXGN1cnJlbnQucHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAA8TkRCQkpH RE1NR0JQQkRFTkxFSUhHRUlOQ0FBQS5qaW1zY2hAbndsaW5rLmNvbT4AAAAAAwAGEHUgb7MDAAcQ RgQAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABKVVNUVE9CRUFMSVRUTEVNT1JFQ0xBUkVB Qk9VSVRUSElTTVlSRVNQT05TRVdPVUxEQkVBU0ZPTExPV1M6MUlUSVNTVEFURURUSEFUVEhFUkVD SUVQVE1VU1RCRURFUkVOQ09EAAAAABpD ------=_NextPart_000_0004_01BF97D2.9CF82E20-- From owner-ietf-smime Sun Mar 26 22:59:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA23065 for ietf-smime-bks; Sun, 26 Mar 2000 22:59:27 -0800 (PST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23060 for ; Sun, 26 Mar 2000 22:59:24 -0800 (PST) Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id QAA32577 return ; Mon, 27 Mar 2000 16:31:35 +0930 (CST) From: "Jim Schaad" To: Cc: "Carlisle Adams" Subject: RE: LAST CALL: draft-ietf-smime-cast-128-01.txt Date: Mon, 27 Mar 2000 16:31:06 +0930 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.2.0.58.20000309113750.00a61330@mail.spyrus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have the following comments on the draft at this stage. I am sorry for being late, but I have been on holidays. 1. In section 3 paragraph 1 -- The size needs to be required for an SMimeCapablity and cannot be MAY. We do binary comparisions to see if the algorithms are the same so there can be no MAY fields. 2. In section 3 -- Again I ask that you include the actual list of bytes that are to be used for the SMimeCaps fields. For an example of what I am looking for you can look at section 7 of CMSKEA. Due to the fact that a binary comparision is being done, it is best to allow for no errors in the encoding of this field. Jim Schaad From owner-ietf-smime Sun Mar 26 23:31:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA23685 for ietf-smime-bks; Sun, 26 Mar 2000 23:31:57 -0800 (PST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23678 for ; Sun, 26 Mar 2000 23:31:54 -0800 (PST) Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id RAA32662 return ; Mon, 27 Mar 2000 17:04:04 +0930 (CST) From: "Jim Schaad" To: Cc: Subject: RE: LAST CALL:draft-ietf-smime-password-02.txt Date: Mon, 27 Mar 2000 17:03:35 +0930 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.2.0.58.20000313151245.0095c7c0@mail.spyrus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are the set of last call comments that I have for this draft. 1. You still have a reference to PKCS #5 v2 in the document. (PKCS#5 v2 is not an information or other RFC.) If you want this document to be on standards track rather than informational then this issue needs to be resolved. 2. Section 2.1. The S/MIME working group is using 88 ASN syntax. The syntax in this section is not. Please correct. PKCS #5 uses current ASN.1 syntax and not the 1988 version, the ASN.1 used is taken straight from the standard. 3. Section 2.1 Why is there ASN here that does not actually provide any useful information. What are the parameters. What is the OID associated with this set of parameters. This is an issue for both the fact that PKCS#5 is not an RFC and the ASN.1 is not 1988. It's copied from PKCS #5 for completeness, I didn't want to include the whole thing verbatim but did want to include enough information that readers wouldn't have to keep flipping back and forth between the two. 4. Section 2.3.1 - I will raise the issue of the fact that the key wrap algorithm is not the same as CMS even though the CMS version is a MUST implement. At a minimum you should make the CMS version the MUST and the version you have in your document an optional version to have. 5. Based on a past email with Carlisle Adams, I think that changing title to "Password-based Encryption for CMS" is a reasonable thing to do. 6. Why does a version with keyDerivation optional exist in this draft? It appears to me that this is exactly the same thing as is done by kekRecipientInfo (i.e. an existing KEK key is used to wrap a CEK key). I would not be in favor of having two different methods for doing this. 7. I don't understand why onlyi the first 3 bytes of the CEK are used for the checksum. What is the problem with using the first 3 bytes of a SHA1 hash. I don't think the performance difference is going to be significant. 8. The test vectors should be modified to use one of the standard CMS algorithms if they are going to be present in the draft. Blowfish is not an algorithm that one should expect most CMS developers to have implemented. RC2 and 3DES are. jim From owner-ietf-smime Mon Mar 27 02:50:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA28531 for ietf-smime-bks; Mon, 27 Mar 2000 02:50:33 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28526 for ; Mon, 27 Mar 2000 02:50:32 -0800 (PST) Received: from rhousley_laptop.spyrus.com (dhcp-193-54.ietf.connect.com.au [169.208.193.54]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id CAA21399; Mon, 27 Mar 2000 02:51:38 -0800 (PST) Message-Id: <4.2.0.58.20000327052814.00a7f950@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 27 Mar 2000 05:32:42 -0500 To: pgut001@cs.aucKland.ac.nz From: Russ Housley Subject: RE: LAST CALL:draft-ietf-smime-password-02.txt Cc: ietf-smime@imc.org In-Reply-To: References: <4.2.0.58.20000313151245.0095c7c0@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: One of the first decisions that the S/MIME working group made was to use 1988 ASN.1. This decision was made for several reasons, including the availability of compilers. So, if you want this to move forward as part of the S/MIME Standards Track document series, then you will have to reverse port the ASN.1. Russ From owner-ietf-smime Mon Mar 27 19:06:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA28083 for ietf-smime-bks; Mon, 27 Mar 2000 19:06:49 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA28079 for ; Mon, 27 Mar 2000 19:06:48 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 22:08:40 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF31965C42@wfhqex01.wangfed.com> From: =?UTF-8?B?UGF3bGluZywgSm9obg==?= To: =?UTF-8?B?J0ppbSBTY2hhYWQgJw==?= , =?UTF-8?B?J0NhbWVyb24gU3RpbGxpb24gJw==?= , =?UTF-8?B?J2lldGYtc21pbWVAaW1jLm9yZyAn?= Cc: =?UTF-8?B?J0JyeWFuIFN0YWF0cyAn?= Subject: =?UTF-8?B?UkU6IEVTUyA6IFNlY3VyZSBSZWNlaXB0IGVuY29kaW5nIHdpdGhp?= =?UTF-8?B?biBFbmNhcHN1bGF0ZWRDb250ZW50SW5mbw==?= Date: Mon, 27 Mar 2000 22:08:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, I agree with all of your statements except for bullet #3. You stated that the OCTET wrapping can be omitted if an ESS receipt content-type is encapsulated within a PKCS#7 signedData. This would cause severe interoperability problems with an RFC 2630/RFC 2634 (a.k.a. CMS/ESS) implementation such as the S/MIME Freeware Library. RFC 2630 (CMS) defines EncapsulatedContentInfo as follows: EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } If the eContent field is present, then the OCTET STRING tag and length octets must be present in the encoding of the signedData. RFC 2634 (ESS), Section 2.4, bullet 9 states: "The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]." Notice the text "defined in [CMS]". A valid encoding of an ESS signed receipt MUST contain the signedData encapContentInfo eContent OCTET STRING tag and length octets. If the eContent OCTET STRING tag and length octets are omitted (as you suggest in your message), then a CMS/ESS implementation cannot decode the message. There is no text in ESS that addresses the inclusion of a receipt content in a PKCS #7 signedData. If there was such text, it would need to state that the ASN.1 DER encoded Receipt content MUST be directly encoded within an OCTET STRING within the PKCS #7 signedData contentInfo content defined in PKCS #7. This is the only way (without changing the CMS encapContentInfo eContent syntax) that signed receipt interoperability can be achieved between CMS/ESS and PKCS #7/ESS implementations. If you believe that there will be PKCS #7/ESS implementations that are sending signed receipts, then the aforementioned text needs to be included in RFC 2634. Thank you for your feedback, -John Pawling From owner-ietf-smime Tue Mar 28 19:13:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21828 for ietf-smime-bks; Tue, 28 Mar 2000 19:13:02 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21824 for ; Tue, 28 Mar 2000 19:12:59 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id PAA15104 for ; Wed, 29 Mar 2000 15:15:08 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95429970802782>; Wed, 29 Mar 2000 15:15:08 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Comments on draft-ietf-smime-compression-00.txt Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Wed, 29 Mar 2000 15:15:08 (NZST) Message-ID: <95429970802782@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does anyone have any further thoughts on compression as a CMS content type vs a MIME type? I think this was more or less beaten to death (and beyond :-) the last time it came up, but if anyone has any further thoughts please post them. (The password issues are being worked on offline, I'll post an update in a day or two). Peter. From owner-ietf-smime Tue Mar 28 19:34:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23578 for ietf-smime-bks; Tue, 28 Mar 2000 19:34:36 -0800 (PST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23566 for ; Tue, 28 Mar 2000 19:34:33 -0800 (PST) Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id NAA06036 return ; Wed, 29 Mar 2000 13:06:43 +0930 (CST) From: "Jim Schaad" To: "Ietf-Smime" Cc: "Russ Housley" Subject: Comments on the RSAES-OAEP draft Date: Wed, 29 Mar 2000 13:06:15 +0930 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Given that the question has been raised on at least one IETF mailing list, it might be advisable to state that the public key algorithm for rsa in a certificate is the same for v1.5 and v2.0. 2. You have consistantly gotten the RFC number for the v2.0 draft incorrect. It is 2437 not 2347. jim From owner-ietf-smime Wed Mar 29 04:19:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA26315 for ietf-smime-bks; Wed, 29 Mar 2000 04:19:27 -0800 (PST) Received: from gate.ritlabs.com (IDENT:root@gw-ritlabs.mldnet.com [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26311 for ; Wed, 29 Mar 2000 04:19:22 -0800 (PST) Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id PAA23567 for ; Wed, 29 Mar 2000 15:24:11 +0300 Date: Wed, 29 Mar 2000 15:21:25 +0300 From: Maxim Masiutin X-Mailer: The Bat! (v1.42 Beta/9) Organization: RIT Research Labs X-Priority: 3 (Normal) Message-ID: <90159940140.20000329@ritlabs.com> To: Peter Gutmann Subject: Compressed Data Content Type for S/MIME Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Peter! There is "PasswordRecipientInfo" defined in "Appendix A: ASN.1 Module" of ietf-smime-compression-00.txt There are no references to PasswordRecipientInfo. How should we handle it? -- Max Masyutin, Software Engineer RIT Research Labs http://www.ritlabs.com/ From owner-ietf-smime Wed Mar 29 05:15:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA27516 for ietf-smime-bks; Wed, 29 Mar 2000 05:15:12 -0800 (PST) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27512 for ; Wed, 29 Mar 2000 05:15:11 -0800 (PST) Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id FAA24625; Wed, 29 Mar 2000 05:17:38 -0800 (PST) From: "Jim Schaad" Reply-to: jimsch@nwlink.com To: ietf-smime@imc.org;weston.nicolls@ey.com;;; Date: Wed, 29 Mar 2000 05:17:38 +0800 Subject: Comments on SecLabel draft Message-id: <38e20272.3756.0@nwlink.com> X-User-Info: 208.212.202.133 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SecLabel 1. Section 1 P2 - Security labels cannot be bound to an encrypted body, only to a signed message. 2. Please give more text explaining the difference between rank and role based security. From the current description they look like the same to me. 3. The Amoco policy description is not clear. From the text I assumed that the confidentiality and integrity were orthogonal axis for make decisions (thus leading to 9 items). Based on the conversation with you this is not true as the policy is choose one of the axis and then the point on the axis. The text should be clarified as to which is correct. 4. Typo - Section 1.2 last para - "while he outer signature" should be "while the". 5. Section 2.2.1.3 -- I don't think that one should provide a syntax for the privacy marks. However giving a couple of the privacy marks or guidelines from the policy on writting them might be useful. Given that a privacy mark is a UTF8 string in the syntax, no addtional ASN syntax is really possible. 6. You say that categories are used informally, however without knowning how they would be used or specified I cannot even hope to offer syntax suggestions. Given that they are informal why would they not be marked as privacy labels. If they are categories then I would expect the policy module to do enforcement thus being informal would cause some difficulties. 7. I suggest that you name Clearance in the ASN sections to be XxxxSection. and the same for the other top level items. http://www.nwlink.com From owner-ietf-smime Wed Mar 29 07:53:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00524 for ietf-smime-bks; Wed, 29 Mar 2000 07:53:54 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00520 for ; Wed, 29 Mar 2000 07:53:51 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA09426; Thu, 30 Mar 2000 03:56:15 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95434537508482>; Thu, 30 Mar 2000 03:56:15 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, max@ritlabs.com Subject: Re: Compressed Data Content Type for S/MIME Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 30 Mar 2000 03:56:15 (NZST) Message-ID: <95434537508482@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maxim Masiutin writes: >There is "PasswordRecipientInfo" defined in "Appendix A: ASN.1 Module" of >ietf-smime-compression-00.txt > >There are no references to PasswordRecipientInfo. How should we handle it? By replacing it with "CompressedDataContent" :-). I copied the OID across from another draft and the text came with it. Also it's listed as (n+1) (equivalent to the '?' or 'TBA' from other CMS drafts) where n currently appears to be 6 (id-mod-ets-eSignature-97), does anyone have any objections to id-mod-compression being 7? In addition it looks like the listed value for id-ct-compressedData has been overtaken by newer drafts, since the highest one listed is id-ct-contentInfo(6) are there any problems with id-ct-compressedData being 7 as well? (Before anyone points this out, I need to update the [CMS] reference as well, I know... draft-00 goes back awhile). Peter. From owner-ietf-smime Wed Mar 29 22:55:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28437 for ietf-smime-bks; Wed, 29 Mar 2000 22:55:39 -0800 (PST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28432 for ; Wed, 29 Mar 2000 22:55:36 -0800 (PST) Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id QAA10863 return ; Thu, 30 Mar 2000 16:27:22 +0930 (CST) From: "Jim Schaad" To: , Subject: RE: Comments on draft-ietf-smime-compression-00.txt Date: Thu, 30 Mar 2000 16:26:54 +0930 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: <95429970802782@kahu.cs.auckland.ac.nz> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My personal opinion is that we have given the MIME people a lot of time to work on this issue. They have not gotten anyplace that I am aware of so I think that we need to do it. If we end up with two ways of doing this then the S/MIME draft could always say what is to be used for that application. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Peter Gutmann Sent: Wednesday, March 29, 2000 3:15 PM To: ietf-smime@imc.org Subject: Comments on draft-ietf-smime-compression-00.txt Does anyone have any further thoughts on compression as a CMS content type vs a MIME type? I think this was more or less beaten to death (and beyond :-) the last time it came up, but if anyone has any further thoughts please post them. (The password issues are being worked on offline, I'll post an update in a day or two). Peter. From owner-ietf-smime Thu Mar 30 09:20:21 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23163 for ietf-smime-bks; Thu, 30 Mar 2000 09:20:21 -0800 (PST) Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23158 for ; Thu, 30 Mar 2000 09:20:19 -0800 (PST) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA18941; Thu, 30 Mar 2000 09:19:46 -0800 (PST) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Mar 2000 09:18:58 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EA60@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Jim Schaad'" , pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org Subject: RE: Comments on draft-ietf-smime-compression-00.txt Date: Thu, 30 Mar 2000 09:18:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0036_01BF9A42.458A3DF0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0036_01BF9A42.458A3DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I think that the real issue is getting a compression algorithm out there, any algorithm will do IMHO. Implementing two sets of switching logic to turn on the compression is not going to be a killer. In fact I think it is likely to be the best solution. Not supporting compression in the base web specs was the biggest mistake we made. We could have made 14K modems look like 28.8 modems if the early browsers had linked to gnuzip. The piece that is currently missing is the means of advertising the capabilities of the client. The biggest problem with messaging is that the 1% of users with ASCII based clients stop the rest of the email population using features like MIME, HTML, S/MIME etc. I can see that we might have problems if we were using a framework like RDF to address this issue and the mechanism did not account for the fact that clients might be able to do compressin in S/MIME but not in MIME (or vice versa). Perhaps the real solution to this problem is to approach it from another direction entirely. Rather than the RDF piecemeal description of supported features maybe we should define client profiles specifying feature sets that make sense. Then we could distribute client capability info with a single certificate attribute. Phill -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Thursday, March 30, 2000 1:57 AM To: pgut001@cs.aucKland.ac.nz; ietf-smime@imc.org Subject: RE: Comments on draft-ietf-smime-compression-00.txt My personal opinion is that we have given the MIME people a lot of time to work on this issue. They have not gotten anyplace that I am aware of so I think that we need to do it. If we end up with two ways of doing this then the S/MIME draft could always say what is to be used for that application. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Peter Gutmann Sent: Wednesday, March 29, 2000 3:15 PM To: ietf-smime@imc.org Subject: Comments on draft-ietf-smime-compression-00.txt Does anyone have any further thoughts on compression as a CMS content type vs a MIME type? I think this was more or less beaten to death (and beyond :-) the last time it came up, but if anyone has any further thoughts please post them. (The password issues are being worked on offline, I'll post an update in a day or two). Peter. ------=_NextPart_000_0036_01BF9A42.458A3DF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDMzMDE3MjAwMVowIwYJKoZI hvcNAQkEMRYEFNtrg7xlSFOO+5ET2XW+udhAHWytMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGArMO1lXHcf2Zuiwq902kkZDe2efqSt/hWy8y30z3+GuP2Kj0HPhmfPjwREWVttTOJ jc+6tO4NxVQoldB4ftd7ItnM6JxKSu8JpWU3gkC7YkmwTQ13p0p4xRJIYx4igGCz9x/0Tr+kO3v3 N82/G0/3ce9qBHNkP3yqv8msK5F/xycAAAAAAAA= ------=_NextPart_000_0036_01BF9A42.458A3DF0-- From owner-ietf-smime Thu Mar 30 16:13:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00127 for ietf-smime-bks; Thu, 30 Mar 2000 16:13:48 -0800 (PST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00120 for ; Thu, 30 Mar 2000 16:13:43 -0800 (PST) Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id JAA13779 return ; Fri, 31 Mar 2000 09:46:14 +0930 (CST) From: "Jim Schaad" To: , "Ietf-Smime" Subject: RE: Comments on SecLabel draft Date: Fri, 31 Mar 2000 09:45:47 +0930 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <38e20272.3756.0@nwlink.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Jim Schaad Sent: Wednesday, March 29, 2000 6:48 AM To: "ietf-smime@imc.org;weston.nicolls"@ey.com;;;; Subject: Comments on SecLabel draft SecLabel 1. Section 1 P2 - Security labels cannot be bound to an encrypted body, only to a signed message. 2. Please give more text explaining the difference between rank and role based security. From the current description they look like the same to me. 3. The Amoco policy description is not clear. From the text I assumed that the confidentiality and integrity were orthogonal axis for make decisions (thus leading to 9 items). Based on the conversation with you this is not true as the policy is choose one of the axis and then the point on the axis. The text should be clarified as to which is correct. 4. Typo - Section 1.2 last para - "while he outer signature" should be "while the". 5. Section 2.2.1.3 -- I don't think that one should provide a syntax for the privacy marks. However giving a couple of the privacy marks or guidelines from the policy on writting them might be useful. Given that a privacy mark is a UTF8 string in the syntax, no addtional ASN syntax is really possible. 6. You say that categories are used informally, however without knowning how they would be used or specified I cannot even hope to offer syntax suggestions. Given that they are informal why would they not be marked as privacy labels. If they are categories then I would expect the policy module to do enforcement thus being informal would cause some difficulties. 7. I suggest that you name Clearance in the ASN sections to be XxxxSection. and the same for the other top level items. http://www.nwlink.com From owner-ietf-smime Thu Mar 30 16:34:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00524 for ietf-smime-bks; Thu, 30 Mar 2000 16:34:34 -0800 (PST) Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00516 for ; Thu, 30 Mar 2000 16:34:31 -0800 (PST) Message-Id: <4.2.0.58.20000330065250.00a41c40@mail.spyrus.com> Date: Thu, 30 Mar 2000 06:54:16 -0500 To: "Jim Schaad" From: Russ Housley Subject: Re: Comments on the RSAES-OAEP draft Cc: "Ietf-Smime" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: 1. Agree. 2. I cut-and-pasted it from RFC 2630, the place were I made the original mistake. Thanks, Russ At 01:06 PM 03/29/2000 +0930, Jim Schaad wrote: >1. Given that the question has been raised on at least one IETF mailing >list, it might be advisable to state that the public key algorithm for rsa >in a certificate is the same for v1.5 and v2.0. > >2. You have consistantly gotten the RFC number for the v2.0 draft >incorrect. It is 2437 not 2347. > > >jim From owner-ietf-smime Thu Mar 30 23:45:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA19854 for ietf-smime-bks; Thu, 30 Mar 2000 23:45:21 -0800 (PST) Received: from atlas.arc.nasa.gov (atlas-ops.arc.nasa.gov [198.123.8.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19848 for ; Thu, 30 Mar 2000 23:45:20 -0800 (PST) Received: from ieca.com (1cust40.tnt2.cbr1.da.uu.net [210.84.115.40]) by atlas.arc.nasa.gov (8.8.5/8.7.3/arc) with ESMTP id XAA01835; Thu, 30 Mar 2000 23:47:34 -0800 (PST) Message-ID: <38E52404.4B18895F@ieca.com> Date: Fri, 31 Mar 2000 02:47:40 -0500 From: Sean Turner Organization: IECA, Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: pgut001@cs.aucKland.ac.nz CC: Jim Schaad , ietf-smime@imc.org Subject: Re: Comments on draft-ietf-smime-compression-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with Jim. Let's do it. spt Jim Schaad wrote: > My personal opinion is that we have given the MIME people a lot of time to > work on this issue. They have not gotten anyplace that I am aware of so I > think that we need to do it. If we end up with two ways of doing this then > the S/MIME draft could always say what is to be used for that application. > > jim > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Peter Gutmann > Sent: Wednesday, March 29, 2000 3:15 PM > To: ietf-smime@imc.org > Subject: Comments on draft-ietf-smime-compression-00.txt > > Does anyone have any further thoughts on compression as a CMS content type > vs a MIME type? I think this was more or less beaten to death (and > beyond :-) the last time it came up, but if anyone has any further thoughts > please post them. > > (The password issues are being worked on offline, I'll post an update in a > day or two). > > Peter. From owner-ietf-smime Sat Apr 1 18:35:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA04926 for ietf-smime-bks; Sat, 1 Apr 2000 18:35:45 -0800 (PST) Received: from www.pressmedia.com.pl ([195.117.30.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04911 for ; Sat, 1 Apr 2000 18:35:41 -0800 (PST) Message-Id: <200004020235.SAA04911@ns.secondary.com> Received: from cranston-ip-1-193.dynamic.ziplink.net by www.pressmedia.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 2CS50T4D; Sun, 2 Apr 2000 04:37:19 +0200 From: "Greg" Subject: Between us... To: look90h X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sat, 01 Apr 2000 20:52:52 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA04919 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E -Commerce, including a merchant account, real-time software and shopping cart. NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE FIRST MONTH FOR FREE. While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for E-commerce when you sign up for our e-commerce hosting plan. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Password generator for membership sites * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! Please reply to: mailto:wrkv@pplmail.com?subject=INFO-PLEASE to receive our FREE information package without obligations. ********************************************************* Remove at mailto:bnm99t@usa.net?subject=remove ********************************************************* From owner-ietf-smime Sat Apr 1 20:11:23 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA16156 for ietf-smime-bks; Sat, 1 Apr 2000 20:11:23 -0800 (PST) Received: from ttic01.tatung.com.tw (IDENT:root@ttic01.tatung.com.tw [139.223.65.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16149 for ; Sat, 1 Apr 2000 20:11:19 -0800 (PST) Received: from kllklk (cranston-ip-1-50.dynamic.ziplink.net [209.206.4.50]) by ttic01.tatung.com.tw (8.9.3/8.9.3) with ESMTP id MAA03816; Sun, 2 Apr 2000 12:11:38 +0800 Message-Id: <200004020411.MAA03816@ttic01.tatung.com.tw> From: "Greg" Subject: Between us... To: look90h@ttic01.tatung.com.tw X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sat, 01 Apr 2000 22:29:24 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA16150 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E -Commerce, including a merchant account, real-time software and shopping cart. NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE FIRST MONTH FOR FREE. While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for E-commerce when you sign up for our e-commerce hosting plan. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Password generator for membership sites * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! Please reply to: mailto:wrkv@pplmail.com?subject=INFO-PLEASE to receive our FREE information package without obligations. ********************************************************* Remove at mailto:bnm99t@usa.net?subject=remove ********************************************************* From owner-ietf-smime Sun Apr 2 11:29:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA08786 for ietf-smime-bks; Sun, 2 Apr 2000 11:29:14 -0700 (PDT) Received: from www.pressmedia.com.pl ([195.117.30.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08782 for ; Sun, 2 Apr 2000 11:29:12 -0700 (PDT) Message-Id: <200004021829.LAA08782@ns.secondary.com> Received: from cranston-ip-1-193.dynamic.ziplink.net by www.pressmedia.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 2CS50T4D; Sun, 2 Apr 2000 04:37:19 +0200 From: "Greg" Subject: Between us... To: look90h X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sat, 01 Apr 2000 20:52:52 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA08783 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E -Commerce, including a merchant account, real-time software and shopping cart. NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE FIRST MONTH FOR FREE. While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for E-commerce when you sign up for our e-commerce hosting plan. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Password generator for membership sites * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! Please reply to: mailto:wrkv@pplmail.com?subject=INFO-PLEASE to receive our FREE information package without obligations. ********************************************************* Remove at mailto:bnm99t@usa.net?subject=remove ********************************************************* From owner-ietf-smime Sun Apr 2 17:52:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA11665 for ietf-smime-bks; Sun, 2 Apr 2000 17:52:25 -0700 (PDT) Received: from mcaprov.mcanet.com.br (mcaprov.mcanet.com.br [200.194.224.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA11661 for ; Sun, 2 Apr 2000 17:52:09 -0700 (PDT) Received: from kllklk (unverified [38.26.242.199]) by mcaprov.mcanet.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 02 Apr 2000 20:50:32 +0000 Message-ID: From: "Harry" Subject: Increase Your Chances To: win28sj X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 02 Apr 2000 17:55:04 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA11662 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you interested in increasing your odds in winning a lottery? To Find out how, Print this email, complete the form & fax it to 407-359-1545 Name: ______________________________ Country: ___________________ST______ Email Address: _____________________ The above information is required to receive information via email ***************************************************************** This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you.This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability.If you are a Washington, Virginia, or California resident please remove yourself. ========================================= If you wish to be removed from future mailings, please Reply to: mailto:binwk@netscape.net?subject=remove =================================================== From owner-ietf-smime Tue Apr 4 16:47:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07915 for ietf-smime-bks; Tue, 4 Apr 2000 16:47:14 -0700 (PDT) Received: from poltegor.igo.wroc.pl (poltegor.igo.wroc.pl [156.17.53.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07910 for ; Tue, 4 Apr 2000 16:47:12 -0700 (PDT) Received: from kllklk (cranston-ip-2-114.dynamic.ziplink.net [209.206.5.114]) by poltegor.igo.wroc.pl (AIX4.2/UCB 8.7/8.7) with ESMTP id BAA18502; Wed, 5 Apr 2000 01:14:57 +0200 (DFT) Message-Id: <200004042314.BAA18502@poltegor.igo.wroc.pl> From: "Wayne" Subject: Top Notch To: foryou9k@poltegor.igo.wroc.pl X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Tue, 04 Apr 2000 18:51:59 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA07911 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:poland4343@bigfoot.com?subject=more_info FOR MORE INFORMATION If you are an entrepreneur or have always wanted to be your own BOSS, read on. We supply state-of-the-art training and a support system that allows you to work your business from your home with just a phone-without cold calling. DO NOT REPLY IF YOU ARE LOOKING FOR A "GET RICH QUICK" SCHEME or some extra cash or if you're lazy. We are only looking for FOCUSED serious entrepreneurs. (Pt/FT) with the DESIRE to improve their lifestyle immediately. /////////////////////////////////////////////////////////// Please remove at mailto:swaqt@doramail.com?subject=remove /////////////////////////////////////////////////////////// From owner-ietf-smime Thu Apr 6 05:33:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA00578 for ietf-smime-bks; Thu, 6 Apr 2000 05:33:16 -0700 (PDT) Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00574 for ; Thu, 6 Apr 2000 05:33:14 -0700 (PDT) Date: 06 Apr 2000 14:34:37 +0200 From: Thierry Van Doninck To: ietf-smime Subject: which usercertificate attribute Message-Id: <0551838EC845D14B*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory. Netscape however looks for a userSMIMEcertificate instead of a userCertificate. Which is the correct attribute to publish Certificates in ? I would think that using 1 certificate for all applications would be a lot more user friendly. I only have one physical passport, why would I need several digital one's ? Thierry eMail : thierry.vandoninck@dexia.be From owner-ietf-smime Thu Apr 6 07:57:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02959 for ietf-smime-bks; Thu, 6 Apr 2000 07:57:56 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02937 for ; Thu, 6 Apr 2000 07:57:51 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA01851 for ; Thu, 6 Apr 2000 07:55:12 -0700 (PDT) Received: from netscape.com ([206.222.244.213]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSLOCS00.0OY; Thu, 6 Apr 2000 08:00:28 -0700 Message-ID: <38ECA68E.A217222@netscape.com> Date: Thu, 06 Apr 2000 08:00:30 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Van Doninck CC: ietf-smime Subject: Re: which usercertificate attribute References: <0551838EC845D14B*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thierry Van Doninck wrote: > Hi, > > When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory. > Netscape however looks for a userSMIMEcertificate instead of a userCertificate. > > Which is the correct attribute to publish Certificates in ? > I would think that using 1 certificate for all applications would be a lot more user friendly. > The userSMIMEcertificate attribute contains additional information about the SMIME recipient, in particular the preferred encryption algorithms. Without this information, the message sender has to guess what algorithms would be acceptable. This is why Communicator used userSMIMEcertificate. More recent versions of SMIME support for Communicator (in particular the PSM security add-on) supports retrieval of the certificates from both attributes in the directory. In addition, PSM has support for automatically retrieving certificates from your primary directory (address book) without manual intervention. Terry Hayes thayes@netscape.com From owner-ietf-smime Thu Apr 6 08:40:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03769 for ietf-smime-bks; Thu, 6 Apr 2000 08:40:50 -0700 (PDT) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03765 for ; Thu, 6 Apr 2000 08:40:48 -0700 (PDT) Received: from rhousley_laptop.spyrus.com.au (va.spyrus.com [205.177.169.194]) by thehub.knight-hub.com (8.9.3/8.9.3) with ESMTP id LAA10863; Thu, 6 Apr 2000 11:41:27 -0400 Message-Id: <4.2.0.58.20000406113958.00a4fe00@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Apr 2000 11:43:21 -0400 To: Thierry Van Doninck From: Russ Housley Subject: Re: which usercertificate attribute Cc: ietf-smime Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thierry: > When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory. > Netscape however looks for a userSMIMEcertificate instead of a userCertificate. > > Which is the correct attribute to publish Certificates in ? > I would think that using 1 certificate for all applications would be a lot more user friendly. See draft-ietf-smime-certdist-04.txt for a description of userSMimeCertificate. I think the document does a good job explaining why userSMimeCertificate and userCertificate both exist. Russ From owner-ietf-smime Fri Apr 7 10:19:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09054 for ietf-smime-bks; Fri, 7 Apr 2000 10:19:36 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09050 for ; Fri, 7 Apr 2000 10:19:34 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA08499 for ; Fri, 7 Apr 2000 13:22:02 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id NAA08490 for ; Fri, 7 Apr 2000 13:22:02 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id NAA28346 for ; Fri, 7 Apr 2000 13:22:33 -0400 (EDT) Message-Id: <200004071722.NAA28346@missi.ncsc.mil> Date: Fri, 7 Apr 2000 13:22:19 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: which usercertificate attribute To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: e7FyxxG+tmYzlbvZgtpdKQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The correct attribute in which to publish end-entity certificates is the one defined by RFC 2587 "LDAPv2 Schema", namely userCertificate. RFC 2632 "S/MIME Version 3 Certificate Handling", section 4, does not specify user agent requirements, leaving implementors on their own to decide how to retrieve certs. It mentions X.500 (presumably meaning DAP) and DNS, but says: "At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message." For son-of-2632, the first paragraph of section 4 needs to be rewritten to reflect the current directory environment. At that time, it should also provide a little more guidance on interoperability. I suggest: "At a minimum, S/MIME user agents MUST support LDAP (RFC 2559) and the LDAP v2 Schema (RFC 2587)." The new section 4 could mention certdist as an option, but standard LDAP should be mandatory. Certdist could (if modified) be used to communicate the recipient's algorithm preferences without containing the recipient's certificate(s). Dave Kemp > From: thayes@netscape.com (Terry Hayes) > > Thierry Van Doninck wrote: > > > Hi, > > > > When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory. > > Netscape however looks for a userSMIMEcertificate instead of a userCertificate. > > > > Which is the correct attribute to publish Certificates in ? > > I would think that using 1 certificate for all applications would be a lot more user friendly. > > > > The userSMIMEcertificate attribute contains additional information about the SMIME recipient, in particular the preferred > encryption algorithms. Without this information, the message sender has to guess what algorithms would be acceptable. This is > why Communicator used userSMIMEcertificate. > > More recent versions of SMIME support for Communicator (in particular the PSM security add-on) supports retrieval of the > certificates from both attributes in the directory. In addition, PSM has support for automatically retrieving certificates > from your primary directory (address book) without manual intervention. > > Terry Hayes > thayes@netscape.com From owner-ietf-smime Fri Apr 7 10:20:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09102 for ietf-smime-bks; Fri, 7 Apr 2000 10:20:08 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09097 for ; Fri, 7 Apr 2000 10:20:07 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA08568 for ; Fri, 7 Apr 2000 13:22:34 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id NAA08564 for ; Fri, 7 Apr 2000 13:22:34 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id NAA28352 for ; Fri, 7 Apr 2000 13:23:06 -0400 (EDT) Message-Id: <200004071723.NAA28352@missi.ncsc.mil> Date: Fri, 7 Apr 2000 13:22:52 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: which usercertificate attribute To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q8nMbHtQLiwjjPX0tKcHwA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Certdist-04 section 4.5 explains: "If the SignedData object is to be published in userSMimeCertificate, the end-entity certificates MAY be omitted from the certificate bag and published in the userCertificates [sic] LDAP attribute instead." How is an application developer supposed to interpret this requirement? I would read it to say that since the EE cert MAY be in either attribute, applications MUST look for it in BOTH attributes. But Terry Hayes' posting indicates that (without an add-on) Communicator does not look in the userCertificate attribute. Section 2 justifies the inclusion of a cert path in the SignedData object by claiming that in non-X.500 (DAP or LDAP) directories it is difficult to impossible to obtain CA certificates. But it does not follow through with that logic by *not* requiring a full cert path when the object *is* stored in an LDAP directory. Section 4.3 should be changed from: "A chain of certificate from the end-entitycertificate(s) to the root certificate(s) MUST be included in the CertificateSet." to: "A chain of certificate from the end-entitycertificate(s) to the root certificate(s) MUST be included in the CertificateSet unless the SignedData object is published in userSMimeCertificate, in which case the CertificateSet MUST be empty." and section 4.5 should be adjusted accordingly. This would ensure that when using LDAP, applications always use the PKIX-standard locations for both CA and EE certificates. Dave Kemp > From: Russ Housley > > See draft-ietf-smime-certdist-04.txt for a description of > userSMimeCertificate. I think the document does a good job explaining why > userSMimeCertificate and userCertificate both exist. > > Russ From owner-ietf-smime Fri Apr 7 12:00:40 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11241 for ietf-smime-bks; Fri, 7 Apr 2000 12:00:40 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11236 for ; Fri, 7 Apr 2000 12:00:39 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 07 Apr 00 12:03:22 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Apr 2000 12:03:22 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C594FAAA@mail.deming.com> From: "Blake Ramsdell" To: "'David P. Kemp'" , ietf-smime@imc.org Subject: RE: which usercertificate attribute Date: Fri, 7 Apr 2000 12:03:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 14F0EF7049102-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This sounds reasonable. I presume that there's going to be a round of edits surrounding a magic date in September... Blake -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Friday, April 07, 2000 10:22 AM To: ietf-smime@imc.org Subject: Re: which usercertificate attribute The correct attribute in which to publish end-entity certificates is the one defined by RFC 2587 "LDAPv2 Schema", namely userCertificate. RFC 2632 "S/MIME Version 3 Certificate Handling", section 4, does not specify user agent requirements, leaving implementors on their own to decide how to retrieve certs. It mentions X.500 (presumably meaning DAP) and DNS, but says: "At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message." For son-of-2632, the first paragraph of section 4 needs to be rewritten to reflect the current directory environment. At that time, it should also provide a little more guidance on interoperability. I suggest: "At a minimum, S/MIME user agents MUST support LDAP (RFC 2559) and the LDAP v2 Schema (RFC 2587)." The new section 4 could mention certdist as an option, but standard LDAP should be mandatory. Certdist could (if modified) be used to communicate the recipient's algorithm preferences without containing the recipient's certificate(s). Dave Kemp > From: thayes@netscape.com (Terry Hayes) > > Thierry Van Doninck wrote: > > > Hi, > > > > When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory. > > Netscape however looks for a userSMIMEcertificate instead of a userCertificate. > > > > Which is the correct attribute to publish Certificates in ? > > I would think that using 1 certificate for all applications would be a lot more user friendly. > > > > The userSMIMEcertificate attribute contains additional information about the SMIME recipient, in particular the preferred > encryption algorithms. Without this information, the message sender has to guess what algorithms would be acceptable. This is > why Communicator used userSMIMEcertificate. > > More recent versions of SMIME support for Communicator (in particular the PSM security add-on) supports retrieval of the > certificates from both attributes in the directory. In addition, PSM has support for automatically retrieving certificates > from your primary directory (address book) without manual intervention. > > Terry Hayes > thayes@netscape.com From owner-ietf-smime Fri Apr 7 14:31:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13517 for ietf-smime-bks; Fri, 7 Apr 2000 14:31:14 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13513 for ; Fri, 7 Apr 2000 14:31:12 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA13063 for ; Sat, 8 Apr 2000 09:34:23 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95514326315978>; Sat, 8 Apr 2000 09:34:23 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Re: which usercertificate attribute Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 8 Apr 2000 09:34:23 (NZST) Message-ID: <95514326315978@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >The new section 4 could mention certdist as an option, but standard LDAP >should be mandatory. Why should it be mandatory? I can see that saying that finding a cert is a good idea, but mandating it is not (there will always be situations where it doesn't make sense), and mandating one particular way of doing it is even worse - even if you are in a situation where retrieving a cert is useful, being forced to do it via LDAP is an unnecessary restriction. Peter. From owner-ietf-smime Sat Apr 8 13:38:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05493 for ietf-smime-bks; Sat, 8 Apr 2000 13:38:21 -0700 (PDT) Received: from relay2.sion.com (root@relay2.sion.com [200.43.36.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05479 for ; Sat, 8 Apr 2000 13:38:18 -0700 (PDT) Received: from PROXY (smtp.sion.com [200.43.36.110]) by relay2.sion.com (8.9.3/8.9.3) with ESMTP id RAA17625 for ; Sat, 8 Apr 2000 17:56:43 -0300 Received: from intranet - 200.43.37.94 by sion.net with Microsoft SMTPSVC; Sat, 8 Apr 2000 17:38:27 -0300 From: "PortalProfesional.com" To: "ietf-smime@imc.org" Date: Sat, 08 Apr 2000 17:40:10 -0300 Subject: LEAME, ES IMPORTANTE - www.portalprofesional.com Reply-To: info@portalprofesional.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 1 Message-ID: <012682738200840PROXY@sion.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Muchas Preguntas: - Estas Buscando Empleo? - Tienes empleo pero quieres uno mejor? - No sabes donde dejar tu Curriculum? - Eres Profesional o a punto de egresar? - Ud es una Empresa y necesita hacer publicidad? - Necesitas EMAIL Gratis? - Necesitas Pagina Web Gratis? - Ud es una Consultora o Empresa y necesita publicar sus Busquedas Laborales? - Nunca encuentras lo que buscas en Internet? UNA SOLA RESPUESTA: www.portalprofesional.com VISITANOS. No te vas a arrepentir! ICQ: 64451825 www.portalprofesional.com.ar From owner-ietf-smime Sat Apr 8 22:03:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05388 for ietf-smime-bks; Sat, 8 Apr 2000 22:03:39 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05382 for ; Sat, 8 Apr 2000 22:03:37 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 08 Apr 2000 23:06:28 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Sat, 08 Apr 2000 23:06:19 -0600 From: "Bob Jueneman" To: , Subject: Re: which usercertificate attribute Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6B32AEC4.FC9D72C4" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_6B32AEC4.FC9D72C4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Peter, At the risk of putting words in David's mouth, I think he was trying to = define a=20 mandatory minimum environment that compliant software could be assumed=20 to support, so as to help ensure interoperability. That certainly shouldn't preclude retrieving certificates some other way, = of=20 course. Bob >>> Peter Gutmann 04/08/00 09:34AM >>> "David P. Kemp" writes: >The new section 4 could mention certdist as an option, but standard = LDAP=20 >should be mandatory. =20 Why should it be mandatory? I can see that saying that finding a cert is a good idea, but mandating it is not (there will always be situations = where it doesn't make sense), and mandating one particular way of doing it is = even worse - even if you are in a situation where retrieving a cert is useful, being forced to do it via LDAP is an unnecessary restriction. Peter. --=_6B32AEC4.FC9D72C4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Peter,
 
At the risk of putting words in David's mouth, I think he was trying = to=20 define a
mandatory minimum environment that compliant software could be = assumed=20
to support, so as to help ensure interoperability.
 
That certainly shouldn't preclude retrieving certificates some other = way,=20 of
course.
 
Bob

>>> Peter Gutmann <pgut001@cs.aucKland.ac.nz>= ;=20 04/08/00 09:34AM >>>
"David P. Kemp" <dpkemp@missi.ncsc.mil&= gt;=20 writes:

>The new section 4 could mention certdist as an option, = but=20 standard LDAP
>should be mandatory. 

Why should it = be=20 mandatory?  I can see that saying that finding a cert is
a good = idea,=20 but mandating it is not (there will always be situations where
it = doesn't=20 make sense), and mandating one particular way of doing it is even
worse = -=20 even if you are in a situation where retrieving a cert is useful,
being= =20 forced to do it via LDAP is an unnecessary=20 restriction.

Peter.

--=_6B32AEC4.FC9D72C4-- From owner-ietf-smime Mon Apr 10 05:43:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13432 for ietf-smime-bks; Mon, 10 Apr 2000 05:43:08 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13428 for ; Mon, 10 Apr 2000 05:43:07 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id IAA17891 for ; Mon, 10 Apr 2000 08:45:29 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id IAA17887 for ; Mon, 10 Apr 2000 08:45:29 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id IAA07830 for ; Mon, 10 Apr 2000 08:46:21 -0400 (EDT) Message-Id: <200004101246.IAA07830@missi.ncsc.mil> Date: Mon, 10 Apr 2000 08:46:00 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: which usercertificate attribute To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JJI8xtBbRS6Zc6mSf2Yuhg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Bob put the right words in my mouth :-). IETF specifications use "MUST", "SHOULD", and "MAY" in a uniform manner to enhance the ability to interoperate. MUST always means "must implement", not "must use". But I meant mandatory in an even more limited sense: *if* applications are going to support LDAP (i.e. X.500 directory attributes) to retrieve certs, then they MUST be able to do it in accordance with the standard LDAP schema. Dave > To: ietf-smime@imc.org > Subject: Re: which usercertificate attribute > > "David P. Kemp" writes: > > >The new section 4 could mention certdist as an option, but standard LDAP > >should be mandatory. > > Why should it be mandatory? I can see that saying that finding a cert is > a good idea, but mandating it is not (there will always be situations where > it doesn't make sense), and mandating one particular way of doing it is even > worse - even if you are in a situation where retrieving a cert is useful, > being forced to do it via LDAP is an unnecessary restriction. > > Peter. From owner-ietf-smime Mon Apr 10 06:51:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14439 for ietf-smime-bks; Mon, 10 Apr 2000 06:51:17 -0700 (PDT) Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14435 for ; Mon, 10 Apr 2000 06:51:16 -0700 (PDT) Received: by MARS with Internet Mail Service (5.5.2650.21) id <2JTDM7AN>; Mon, 10 Apr 2000 09:54:05 -0400 Message-ID: From: Aram Perez To: ietf-smime@imc.org Subject: RE: which usercertificate attribute Date: Mon, 10 Apr 2000 09:53:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David is right. Why have standards if you can't interoperate with other implementations? Over a year ago I asked if there was a standard way of getting a user's certificate from an LDAP directory. While I received a number of replys, not one reply said: There is a standard LDAP schema which you can use. Regards, Aram Perez -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Monday, April 10, 2000 8:46 AM To: ietf-smime@imc.org Subject: Re: which usercertificate attribute Peter, Bob put the right words in my mouth :-). IETF specifications use "MUST", "SHOULD", and "MAY" in a uniform manner to enhance the ability to interoperate. MUST always means "must implement", not "must use". But I meant mandatory in an even more limited sense: *if* applications are going to support LDAP (i.e. X.500 directory attributes) to retrieve certs, then they MUST be able to do it in accordance with the standard LDAP schema. Dave > To: ietf-smime@imc.org > Subject: Re: which usercertificate attribute > > "David P. Kemp" writes: > > >The new section 4 could mention certdist as an option, but standard LDAP > >should be mandatory. > > Why should it be mandatory? I can see that saying that finding a cert is > a good idea, but mandating it is not (there will always be situations where > it doesn't make sense), and mandating one particular way of doing it is even > worse - even if you are in a situation where retrieving a cert is useful, > being forced to do it via LDAP is an unnecessary restriction. > > Peter. From owner-ietf-smime Mon Apr 10 07:54:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15456 for ietf-smime-bks; Mon, 10 Apr 2000 07:54:41 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15451 for ; Mon, 10 Apr 2000 07:54:39 -0700 (PDT) Received: from wwilliams4 (wwilliams2.bbn.com [171.78.1.7]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id KAA10546; Mon, 10 Apr 2000 10:58:12 -0400 (EDT) From: "Walter Williams" To: "Aram Perez" , Subject: RE: which usercertificate attribute Date: Mon, 10 Apr 2000 10:49:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, smimeUserCertificate and userCertificate objects are both part of the IETF standard organizationalPerson and inetOrgPerson schemas. The first is RFC2256 if my memory does not fail me and the second is a draft on the standards track, and has been widely adopted in the industry. Therefor: There is a standard LDAP schema which you can use Walter Williams TSD Senior IT Analyst Genuity Please note: GTE Internetworking is now Genuity -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Aram Perez Sent: Monday, April 10, 2000 9:54 AM To: ietf-smime@imc.org Subject: RE: which usercertificate attribute David is right. Why have standards if you can't interoperate with other implementations? Over a year ago I asked if there was a standard way of getting a user's certificate from an LDAP directory. While I received a number of replys, not one reply said: There is a standard LDAP schema which you can use. Regards, Aram Perez -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Monday, April 10, 2000 8:46 AM To: ietf-smime@imc.org Subject: Re: which usercertificate attribute Peter, Bob put the right words in my mouth :-). IETF specifications use "MUST", "SHOULD", and "MAY" in a uniform manner to enhance the ability to interoperate. MUST always means "must implement", not "must use". But I meant mandatory in an even more limited sense: *if* applications are going to support LDAP (i.e. X.500 directory attributes) to retrieve certs, then they MUST be able to do it in accordance with the standard LDAP schema. Dave > To: ietf-smime@imc.org > Subject: Re: which usercertificate attribute > > "David P. Kemp" writes: > > >The new section 4 could mention certdist as an option, but standard LDAP > >should be mandatory. > > Why should it be mandatory? I can see that saying that finding a cert is > a good idea, but mandating it is not (there will always be situations where > it doesn't make sense), and mandating one particular way of doing it is even > worse - even if you are in a situation where retrieving a cert is useful, > being forced to do it via LDAP is an unnecessary restriction. > > Peter. From owner-ietf-smime Mon Apr 10 07:29:43 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15064 for ietf-smime-bks; Mon, 10 Apr 2000 07:29:43 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15060 for ; Mon, 10 Apr 2000 07:29:42 -0700 (PDT) Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA03395; Mon, 10 Apr 2000 07:32:23 -0700 (PDT) Message-Id: <4.2.0.58.20000410092030.00a5db60@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 X-Priority: 2 (High) Date: Mon, 10 Apr 2000 09:46:44 -0400 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: Ready for IETF Last Call: draft-ietf-smime-cast-128-02.txt Cc: ietf-smime@imc.org, ietf-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff & Marcus: The S/MIME Working Group is finished with the CAST-128 algorithm specification. It is ready for IETF Last Call and publication as a Proposed Standard RFC. Russ From owner-ietf-smime Mon Apr 10 13:59:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22710 for ietf-smime-bks; Mon, 10 Apr 2000 13:59:22 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22706 for ; Mon, 10 Apr 2000 13:59:21 -0700 (PDT) Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA08082; Mon, 10 Apr 2000 14:02:16 -0700 (PDT) Message-Id: <4.2.0.58.20000410163516.00a5d5c0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Apr 2000 16:37:01 -0400 To: "David P. Kemp" From: Russ Housley Subject: Re: which usercertificate attribute Cc: ietf-smime@imc.org In-Reply-To: <200004071722.NAA28346@missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave: I am not convinced that LDAP support is a MUST requirement. S/MIMEv2 included a mechanism to support clients that are directory-impaired. So far, this capability has remained in S/MIMEv3. If LDAP is supported, then I agree with the things you say. Russ At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote: >The correct attribute in which to publish end-entity certificates is >the one defined by RFC 2587 "LDAPv2 Schema", namely userCertificate. > >RFC 2632 "S/MIME Version 3 Certificate Handling", section 4, does not >specify user agent requirements, leaving implementors on their own to >decide how to retrieve certs. It mentions X.500 (presumably meaning >DAP) and DNS, but says: > > "At a minimum, for initial S/MIME deployment, a user agent > could automatically generate a message to an intended recipient > requesting that recipient's certificate in a signed return > message." > >For son-of-2632, the first paragraph of section 4 needs to be rewritten >to reflect the current directory environment. At that time, it should >also provide a little more guidance on interoperability. I suggest: > > "At a minimum, S/MIME user agents MUST support LDAP (RFC 2559) and > the LDAP v2 Schema (RFC 2587)." > >The new section 4 could mention certdist as an option, but standard >LDAP should be mandatory. Certdist could (if modified) be used to >communicate the recipient's algorithm preferences without containing >the recipient's certificate(s). > >Dave Kemp > > > > > > > From: thayes@netscape.com (Terry Hayes) > > > > Thierry Van Doninck wrote: > > > > > Hi, > > > > > > When I use Netscape Communicator as a mail client, I can 'get' the >certificates of my correspondents from a ldap directory. > > > Netscape however looks for a userSMIMEcertificate instead of a >userCertificate. > > > > > > Which is the correct attribute to publish Certificates in ? > > > I would think that using 1 certificate for all applications would be > a lot >more user friendly. > > > > > > > The userSMIMEcertificate attribute contains additional information > about the >SMIME recipient, in particular the preferred > > encryption algorithms. Without this information, the message sender > has to >guess what algorithms would be acceptable. This is > > why Communicator used userSMIMEcertificate. > > > > More recent versions of SMIME support for Communicator (in particular > the PSM >security add-on) supports retrieval of the > > certificates from both attributes in the directory. In addition, PSM has >support for automatically retrieving certificates > > from your primary directory (address book) without manual intervention. > > > > Terry Hayes > > thayes@netscape.com From owner-ietf-smime Mon Apr 10 13:59:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22705 for ietf-smime-bks; Mon, 10 Apr 2000 13:59:21 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22701 for ; Mon, 10 Apr 2000 13:59:20 -0700 (PDT) Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA08077; Mon, 10 Apr 2000 14:02:04 -0700 (PDT) Message-Id: <4.2.0.58.20000410155350.00a4b640@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Apr 2000 16:34:33 -0400 To: "David P. Kemp" From: Russ Housley Subject: Re: which usercertificate attribute Cc: ietf-smime@imc.org In-Reply-To: <200004071723.NAA28352@missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave: Of course, Jim Schaad should be the one to answer this question. He is the author of CERTDIST. Note: The CERTDIST document is in Working Group Last Call, so if there are issues, they need to be resolved NOW. The paragraph that you are talking about was added because if comments received from Ell Gardner at MITRE. If memory serves, she was concerned about two locations in the Directory for the same information. The paragrah that you quote is Jim Schaad's proposed solution: Get the certs from userCertificates and the algorithm preference information userSMimeCertificate. Russ At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote: >Russ, > >Certdist-04 section 4.5 explains: > > "If the SignedData object is to be published in userSMimeCertificate, > the end-entity certificates MAY be omitted from the certificate bag > and published in the userCertificates [sic] LDAP attribute instead." > >How is an application developer supposed to interpret this requirement? >I would read it to say that since the EE cert MAY be in either attribute, >applications MUST look for it in BOTH attributes. But Terry Hayes' >posting indicates that (without an add-on) Communicator does not look >in the userCertificate attribute. > >Section 2 justifies the inclusion of a cert path in the SignedData >object by claiming that in non-X.500 (DAP or LDAP) directories it is >difficult to impossible to obtain CA certificates. But it does not >follow through with that logic by *not* requiring a full cert path when >the object *is* stored in an LDAP directory. > >Section 4.3 should be changed from: > > "A chain of certificate from the end-entitycertificate(s) to the root > certificate(s) MUST be included in the CertificateSet." > >to: > > "A chain of certificate from the end-entitycertificate(s) to the root > certificate(s) MUST be included in the CertificateSet unless the > SignedData object is published in userSMimeCertificate, in which case > the CertificateSet MUST be empty." > >and section 4.5 should be adjusted accordingly. > >This would ensure that when using LDAP, applications always use the >PKIX-standard locations for both CA and EE certificates. > >Dave Kemp > > > > > > From: Russ Housley > > > > See draft-ietf-smime-certdist-04.txt for a description of > > userSMimeCertificate. I think the document does a good job explaining why > > userSMimeCertificate and userCertificate both exist. > > > > Russ From owner-ietf-smime Mon Apr 10 15:01:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA23879 for ietf-smime-bks; Mon, 10 Apr 2000 15:01:10 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA23875 for ; Mon, 10 Apr 2000 15:01:09 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 10 Apr 00 15:04:09 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Apr 2000 15:04:09 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C594FAF3@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: CERTDIST comments Date: Mon, 10 Apr 2000 15:04:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 14EC905360985-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Whoops. I should pay more attention to deadlines ;). In the example, the S/MIME capability: SEQUENCE { OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2) INTEGER 160 } should probably be: SEQUENCE { OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2) INTEGER 40 } (notice the INTEGER 40). In the capabilities, the keylengths for RC2 are stored unobfuscated. Since this is an example, it may not be important that this be correct. Blake -- Blake C. Ramsdell Tumbleweed Communications (formerly Worldtalk Corp.) For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime Tue Apr 11 03:50:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11642 for ietf-smime-bks; Tue, 11 Apr 2000 03:50:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11638 for ; Tue, 11 Apr 2000 03:50:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27992; Tue, 11 Apr 2000 06:53:32 -0400 (EDT) Message-Id: <200004111053.GAA27992@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cast-128-02.txt Date: Tue, 11 Apr 2000 06:53:32 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the CAST-128 Encryption Algorithm in CMS Author(s) : C. Adams Filename : draft-ietf-smime-cast-128-02.txt Pages : 6 Date : 10-Apr-00 This document specifies how to incorporate CAST-128 [RFC2144] into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification [RFC2630] for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cast-128-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cast-128-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000410122630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cast-128-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cast-128-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000410122630.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Apr 11 03:49:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11636 for ietf-smime-bks; Tue, 11 Apr 2000 03:49:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11632 for ; Tue, 11 Apr 2000 03:49:54 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27980; Tue, 11 Apr 2000 06:53:26 -0400 (EDT) Message-Id: <200004111053.GAA27980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-03.txt Date: Tue, 11 Apr 2000 06:53:26 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Incorporation of IDEA Encryption Algorithm in S/MIME Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-03.txt Pages : 6 Date : 10-Apr-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000410122620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000410122620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Apr 11 06:19:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19221 for ietf-smime-bks; Tue, 11 Apr 2000 06:19:12 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19217 for ; Tue, 11 Apr 2000 06:19:11 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA27916 for ; Tue, 11 Apr 2000 09:21:31 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id JAA27908 for ; Tue, 11 Apr 2000 09:21:31 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id JAA07907 for ; Tue, 11 Apr 2000 09:22:30 -0400 (EDT) Message-Id: <200004111322.JAA07907@missi.ncsc.mil> Date: Tue, 11 Apr 2000 09:22:08 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: which usercertificate attribute To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HtSfrKcxfw7kaMm87Y9Qkg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, I too would like to resolve the outstanding issue of what attributes are used to hold certificates, both End Entity and CA, in the case where certificates are retrieved from an LDAP directory. As I noted after the 22 October 1999 announcement of working group last call for certdist-04, the paragraph added in response to Ella's concern is an improvement, however it does not go far enough because it does not require a single location that all applications can count on in order to ensure interoperability. The text I proposed, quoted below, does ensure that all applications can count on finding both EE and CA certs in the PKIX-standard location, but it is not the only possible text which would ensure this result. If Jim or anyone else has alternate proposed text for interoperability when using LDAP, please put it forward. Blake agrees that the PKIX attributes should be mandatory for LDAP in the SMIME cert-handling specification. I am concerned that if certdist-04 becomes an RFC, it will conflict with cert-handling and perpetuate confusion over which LDAP attributes should be used. It will result in hard-to-diagnose problems when some apps look in one directory attribute and other apps look elsewhere, and it would not ensure that SMIME and non-SMIME applications can share the same directory infrastructure. Can we get a clear statement that when the smimeUserCertificate attribute is populated in an LDAP directory, it contains NO certificates? Regards, Dave > Date: Mon, 10 Apr 2000 16:34:33 -0400 > To: "David P. Kemp" > From: Russ Housley > Subject: Re: which usercertificate attribute > Cc: ietf-smime@imc.org > > Dave: > > Of course, Jim Schaad should be the one to answer this question. He is the > author of CERTDIST. Note: The CERTDIST document is in Working Group Last > Call, so if there are issues, they need to be resolved NOW. > > The paragraph that you are talking about was added because if comments > received from Ell Gardner at MITRE. If memory serves, she was concerned > about two locations in the Directory for the same information. The > paragrah that you quote is Jim Schaad's proposed solution: Get the certs > from userCertificates and the algorithm preference information > userSMimeCertificate. > > Russ > > > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote: > > >Russ, > > > >Certdist-04 section 4.5 explains: > > > > "If the SignedData object is to be published in userSMimeCertificate, > > the end-entity certificates MAY be omitted from the certificate bag > > and published in the userCertificates [sic] LDAP attribute instead." > > > >How is an application developer supposed to interpret this requirement? > >I would read it to say that since the EE cert MAY be in either attribute, > >applications MUST look for it in BOTH attributes. But Terry Hayes' > >posting indicates that (without an add-on) Communicator does not look > >in the userCertificate attribute. > > > >Section 2 justifies the inclusion of a cert path in the SignedData > >object by claiming that in non-X.500 (DAP or LDAP) directories it is > >difficult to impossible to obtain CA certificates. But it does not > >follow through with that logic by *not* requiring a full cert path when > >the object *is* stored in an LDAP directory. > > > >Section 4.3 should be changed from: > > > > "A chain of certificate from the end-entitycertificate(s) to the root > > certificate(s) MUST be included in the CertificateSet." > > > >to: > > > > "A chain of certificate from the end-entitycertificate(s) to the root > > certificate(s) MUST be included in the CertificateSet unless the > > SignedData object is published in userSMimeCertificate, in which case > > the CertificateSet MUST be empty." > > > >and section 4.5 should be adjusted accordingly. > > > >This would ensure that when using LDAP, applications always use the > >PKIX-standard locations for both CA and EE certificates. > > > >Dave Kemp From owner-ietf-smime Tue Apr 11 07:09:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19846 for ietf-smime-bks; Tue, 11 Apr 2000 07:09:58 -0700 (PDT) Received: from solo.verkstad.net (solo.verkstad.net [192.71.20.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19841 for ; Tue, 11 Apr 2000 07:09:56 -0700 (PDT) Received: from verkstad.net (luke.verkstad.net [192.36.157.24]) by solo.verkstad.net (8.9.1/8.9.1) with ESMTP id QAA00123 for ; Tue, 11 Apr 2000 16:13:27 +0200 Message-ID: <38F33394.CB5A17F8@verkstad.net> Date: Tue, 11 Apr 2000 16:15:48 +0200 From: Luis Barriga Reply-To: Luis.Barriga@ericsson.com Organization: Ericsson Research X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: IETF SMIME List Subject: Domain-to-point security services & DOMSEC Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a common scenario that I believe should be addressed within this group. I'll refer to it as domain-to-point secure messaging and it looks as follows: A user A@ISP.com wishes to communicate *securely* with a another user B@Company.com. The user B@Company.com doesn't have a cert (or if he does A@ISP.com doesn't know it). I see this as a common case, when companies start migrating to PKI and: (1) A@ISP.com is actually a user A@Company.com, who has temporarily left his corporate premises and has a public email account at an POP/IMAP service provider. A wants to exchange email securely with colleagues at the Company, but not all of them have certs. (2) A@ISP.com is an external user with no association with Corporate.Com, but who wants to send important secure email to B@Company.com. A@ISP.com can't access the Company's PKI. To solve this, the Company can deploy a domain securiy service, sort of S/MIME proxy with public cert associated with Smime-proxy@Company.com. The user A@ISP.com (the point) could then send S/MIME to this proxy (the domain) with request to forward the email to the end user B@Company.com. If A also has a cert, then B can reply securely directly or via the S/MIME proxy, provided that the proxy has access to the A's PKI (Company.Com or ISP.com). BTW, this scheme also allows users to store corporate email on unstrusted public POP/IMAP services providers. It can also be used for secure mailing lists and cert distribution. My question to You folks is: 1. Is there enough interest out there to work towards a draft? 2. It seems that this falls within the DOMSEC draft, but the scenario above is not explicitly addressed. Any opinion on this? 3. Anybody else done something similar? ------ Luis Barriga Ericsson Research From owner-ietf-smime Tue Apr 11 20:22:44 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA27196 for ietf-smime-bks; Tue, 11 Apr 2000 20:22:44 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27188 for ; Tue, 11 Apr 2000 20:22:42 -0700 (PDT) Received: from rhousley_laptop.spyrus.com.au (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id UAA22035; Tue, 11 Apr 2000 20:26:12 -0700 (PDT) Message-Id: <4.2.0.58.20000411230325.00a6b4c0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 11 Apr 2000 23:11:06 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: CERTDIST Cc: jis@mit.edu, MLeech@nortel.ca In-Reply-To: <200004111322.JAA07907@missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: It is clear to me that we have not reached consensus on CERTDIST. I cannot recommend forwarding this document to the IESG until this certificates issue is resolved. I hope that the most interested parties can have an objective discussion and develop a solution that aligns with the PKIX LDAP schema. Russ At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote: >Russ, > >I too would like to resolve the outstanding issue of what attributes >are used to hold certificates, both End Entity and CA, >in the case where certificates are retrieved from an LDAP directory. > >As I noted after the 22 October 1999 announcement of working group last >call for certdist-04, the paragraph added in response to Ella's concern >is an improvement, however it does not go far enough because it does >not require a single location that all applications can count on in >order to ensure interoperability. The text I proposed, quoted below, >does ensure that all applications can count on finding both EE and CA >certs in the PKIX-standard location, but it is not the only possible >text which would ensure this result. If Jim or anyone else has >alternate proposed text for interoperability when using LDAP, please >put it forward. > >Blake agrees that the PKIX attributes should be mandatory for LDAP in the >SMIME cert-handling specification. I am concerned that if certdist-04 >becomes an RFC, it will conflict with cert-handling and perpetuate >confusion over which LDAP attributes should be used. It will result >in hard-to-diagnose problems when some apps look in one directory >attribute and other apps look elsewhere, and it would not ensure >that SMIME and non-SMIME applications can share the same directory >infrastructure. > >Can we get a clear statement that when the smimeUserCertificate >attribute is populated in an LDAP directory, it contains NO >certificates? > >Regards, >Dave > > > > > > Date: Mon, 10 Apr 2000 16:34:33 -0400 > > To: "David P. Kemp" > > From: Russ Housley > > Subject: Re: which usercertificate attribute > > Cc: ietf-smime@imc.org > > > > Dave: > > > > Of course, Jim Schaad should be the one to answer this question. He is > the > > author of CERTDIST. Note: The CERTDIST document is in Working Group Last > > Call, so if there are issues, they need to be resolved NOW. > > > > The paragraph that you are talking about was added because if comments > > received from Ell Gardner at MITRE. If memory serves, she was concerned > > about two locations in the Directory for the same information. The > > paragrah that you quote is Jim Schaad's proposed solution: Get the certs > > from userCertificates and the algorithm preference information > > userSMimeCertificate. > > > > Russ > > > > > > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote: > > > > >Russ, > > > > > >Certdist-04 section 4.5 explains: > > > > > > "If the SignedData object is to be published in userSMimeCertificate, > > > the end-entity certificates MAY be omitted from the certificate bag > > > and published in the userCertificates [sic] LDAP attribute instead." > > > > > >How is an application developer supposed to interpret this requirement? > > >I would read it to say that since the EE cert MAY be in either attribute, > > >applications MUST look for it in BOTH attributes. But Terry Hayes' > > >posting indicates that (without an add-on) Communicator does not look > > >in the userCertificate attribute. > > > > > >Section 2 justifies the inclusion of a cert path in the SignedData > > >object by claiming that in non-X.500 (DAP or LDAP) directories it is > > >difficult to impossible to obtain CA certificates. But it does not > > >follow through with that logic by *not* requiring a full cert path when > > >the object *is* stored in an LDAP directory. > > > > > >Section 4.3 should be changed from: > > > > > > "A chain of certificate from the end-entitycertificate(s) to the root > > > certificate(s) MUST be included in the CertificateSet." > > > > > >to: > > > > > > "A chain of certificate from the end-entitycertificate(s) to the root > > > certificate(s) MUST be included in the CertificateSet unless the > > > SignedData object is published in userSMimeCertificate, in which case > > > the CertificateSet MUST be empty." > > > > > >and section 4.5 should be adjusted accordingly. > > > > > >This would ensure that when using LDAP, applications always use the > > >PKIX-standard locations for both CA and EE certificates. > > > > > >Dave Kemp From owner-ietf-smime Wed Apr 12 08:44:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10269 for ietf-smime-bks; Wed, 12 Apr 2000 08:44:19 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10264 for ; Wed, 12 Apr 2000 08:44:18 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <2X4T77A6>; Wed, 12 Apr 2000 11:47:27 -0400 Message-ID: From: Mike Just To: ietf-smime@imc.org Cc: "'dpkemp@missi.ncsc.mil'" , "'Russ Housley'" Subject: RE: CERTDIST Date: Wed, 12 Apr 2000 11:47:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Two points. 1) I agree with David. The document must be clear that if using LDAP, user certificates should be in the userCertificate attribute; user certificates MUST NOT be in the userSMimeCertificate attribute. (In other words, userSMimeCertificate is only used as a source of a user's S/MIME capabilities.) 2) The document doesn't specify the behaviour of a client in the case that the userSMimeCertificate attribute is not populated (with the user's S/MIME capabilities). This might only require a reference to the similar discussion in RFC 2633. Though there should be some indication that the userSMimeCertificate attribute is not required to be populated in an entry. Mike Just > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Tuesday, April 11, 2000 11:11 PM > To: ietf-smime@imc.org > Cc: jis@mit.edu; MLeech@nortel.ca > Subject: CERTDIST > > > All: > > It is clear to me that we have not reached consensus on > CERTDIST. I cannot > recommend forwarding this document to the IESG until this > certificates > issue is resolved. I hope that the most interested parties > can have an > objective discussion and develop a solution that aligns with > the PKIX LDAP > schema. > > Russ > > At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote: > >Russ, > > > >I too would like to resolve the outstanding issue of what attributes > >are used to hold certificates, both End Entity and CA, > >in the case where certificates are retrieved from an LDAP directory. > > > >As I noted after the 22 October 1999 announcement of working > group last > >call for certdist-04, the paragraph added in response to > Ella's concern > >is an improvement, however it does not go far enough because it does > >not require a single location that all applications can count on in > >order to ensure interoperability. The text I proposed, > quoted below, > >does ensure that all applications can count on finding both EE and CA > >certs in the PKIX-standard location, but it is not the only possible > >text which would ensure this result. If Jim or anyone else has > >alternate proposed text for interoperability when using LDAP, please > >put it forward. > > > >Blake agrees that the PKIX attributes should be mandatory > for LDAP in the > >SMIME cert-handling specification. I am concerned that if > certdist-04 > >becomes an RFC, it will conflict with cert-handling and perpetuate > >confusion over which LDAP attributes should be used. It will result > >in hard-to-diagnose problems when some apps look in one directory > >attribute and other apps look elsewhere, and it would not ensure > >that SMIME and non-SMIME applications can share the same directory > >infrastructure. > > > >Can we get a clear statement that when the smimeUserCertificate > >attribute is populated in an LDAP directory, it contains NO > >certificates? > > > >Regards, > >Dave > > > > > > > > > > > Date: Mon, 10 Apr 2000 16:34:33 -0400 > > > To: "David P. Kemp" > > > From: Russ Housley > > > Subject: Re: which usercertificate attribute > > > Cc: ietf-smime@imc.org > > > > > > Dave: > > > > > > Of course, Jim Schaad should be the one to answer this > question. He is > > the > > > author of CERTDIST. Note: The CERTDIST document is in > Working Group Last > > > Call, so if there are issues, they need to be resolved NOW. > > > > > > The paragraph that you are talking about was added > because if comments > > > received from Ell Gardner at MITRE. If memory serves, > she was concerned > > > about two locations in the Directory for the same > information. The > > > paragrah that you quote is Jim Schaad's proposed > solution: Get the certs > > > from userCertificates and the algorithm preference information > > > userSMimeCertificate. > > > > > > Russ > > > > > > > > > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote: > > > > > > >Russ, > > > > > > > >Certdist-04 section 4.5 explains: > > > > > > > > "If the SignedData object is to be published in > userSMimeCertificate, > > > > the end-entity certificates MAY be omitted from the > certificate bag > > > > and published in the userCertificates [sic] LDAP > attribute instead." > > > > > > > >How is an application developer supposed to interpret > this requirement? > > > >I would read it to say that since the EE cert MAY be in > either attribute, > > > >applications MUST look for it in BOTH attributes. But > Terry Hayes' > > > >posting indicates that (without an add-on) Communicator > does not look > > > >in the userCertificate attribute. > > > > > > > >Section 2 justifies the inclusion of a cert path in the > SignedData > > > >object by claiming that in non-X.500 (DAP or LDAP) > directories it is > > > >difficult to impossible to obtain CA certificates. But > it does not > > > >follow through with that logic by *not* requiring a full > cert path when > > > >the object *is* stored in an LDAP directory. > > > > > > > >Section 4.3 should be changed from: > > > > > > > > "A chain of certificate from the > end-entitycertificate(s) to the root > > > > certificate(s) MUST be included in the CertificateSet." > > > > > > > >to: > > > > > > > > "A chain of certificate from the > end-entitycertificate(s) to the root > > > > certificate(s) MUST be included in the CertificateSet > unless the > > > > SignedData object is published in > userSMimeCertificate, in which case > > > > the CertificateSet MUST be empty." > > > > > > > >and section 4.5 should be adjusted accordingly. > > > > > > > >This would ensure that when using LDAP, applications > always use the > > > >PKIX-standard locations for both CA and EE certificates. > > > > > > > >Dave Kemp > From owner-ietf-smime Wed Apr 12 11:30:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA15264 for ietf-smime-bks; Wed, 12 Apr 2000 11:30:22 -0700 (PDT) Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15260 for ; Wed, 12 Apr 2000 11:30:20 -0700 (PDT) Received: from dtasi1 (null@demeter.veritas.com [204.177.156.26]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with SMTP id e3CIXgb18510; Wed, 12 Apr 2000 11:33:42 -0700 (PDT) Message-Id: <3.0.5.32.20000412113339.00923100@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 12 Apr 2000 11:33:39 -0700 To: Mike Just , ietf-smime@imc.org From: Bruce Greenblatt Subject: RE: CERTDIST Cc: "'dpkemp@missi.ncsc.mil'" , "'Russ Housley'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As long as we're talking about where to put certificates, I thought that I'd point out a draft that I wrote, that I received some pretty good feedback on. Check out the draft with the title: "LDAP Object Class for Holding Certificate Information" at your favorite ietf drafts site, e.g.: http://search.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema -02.txt It defines a "certificateType" structural object class, and "Use the certificateType structural class to indicate that an object in the directory is a specific type of certificate. Each cer- tificateType object in the directory appears directly beneath the owner of the certificate in the directory hierarchy." Comments are welcome... Cheers, Bruce At 11:47 AM 4/12/2000 -0400, Mike Just wrote: >Two points. > >1) I agree with David. The document must be clear that if using LDAP, user >certificates should be in the userCertificate attribute; user certificates >MUST NOT be in the userSMimeCertificate attribute. (In other words, >userSMimeCertificate is only used as a source of a user's S/MIME >capabilities.) > >2) The document doesn't specify the behaviour of a client in the case that >the userSMimeCertificate attribute is not populated (with the user's S/MIME >capabilities). This might only require a reference to the similar >discussion in RFC 2633. Though there should be some indication that the >userSMimeCertificate attribute is not required to be populated in an entry. > >Mike Just > > >> -----Original Message----- >> From: Russ Housley [mailto:housley@spyrus.com] >> Sent: Tuesday, April 11, 2000 11:11 PM >> To: ietf-smime@imc.org >> Cc: jis@mit.edu; MLeech@nortel.ca >> Subject: CERTDIST >> >> >> All: >> >> It is clear to me that we have not reached consensus on >> CERTDIST. I cannot >> recommend forwarding this document to the IESG until this >> certificates >> issue is resolved. I hope that the most interested parties >> can have an >> objective discussion and develop a solution that aligns with >> the PKIX LDAP >> schema. >> >> Russ >> >> At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote: >> >Russ, >> > >> >I too would like to resolve the outstanding issue of what attributes >> >are used to hold certificates, both End Entity and CA, >> >in the case where certificates are retrieved from an LDAP directory. >> > >> >As I noted after the 22 October 1999 announcement of working >> group last >> >call for certdist-04, the paragraph added in response to >> Ella's concern >> >is an improvement, however it does not go far enough because it does >> >not require a single location that all applications can count on in >> >order to ensure interoperability. The text I proposed, >> quoted below, >> >does ensure that all applications can count on finding both EE and CA >> >certs in the PKIX-standard location, but it is not the only possible >> >text which would ensure this result. If Jim or anyone else has >> >alternate proposed text for interoperability when using LDAP, please >> >put it forward. >> > >> >Blake agrees that the PKIX attributes should be mandatory >> for LDAP in the >> >SMIME cert-handling specification. I am concerned that if >> certdist-04 >> >becomes an RFC, it will conflict with cert-handling and perpetuate >> >confusion over which LDAP attributes should be used. It will result >> >in hard-to-diagnose problems when some apps look in one directory >> >attribute and other apps look elsewhere, and it would not ensure >> >that SMIME and non-SMIME applications can share the same directory >> >infrastructure. >> > >> >Can we get a clear statement that when the smimeUserCertificate >> >attribute is populated in an LDAP directory, it contains NO >> >certificates? >> > >> >Regards, >> >Dave >> > >> > >> > >> > >> > > Date: Mon, 10 Apr 2000 16:34:33 -0400 >> > > To: "David P. Kemp" >> > > From: Russ Housley >> > > Subject: Re: which usercertificate attribute >> > > Cc: ietf-smime@imc.org >> > > >> > > Dave: >> > > >> > > Of course, Jim Schaad should be the one to answer this >> question. He is >> > the >> > > author of CERTDIST. Note: The CERTDIST document is in >> Working Group Last >> > > Call, so if there are issues, they need to be resolved NOW. >> > > >> > > The paragraph that you are talking about was added >> because if comments >> > > received from Ell Gardner at MITRE. If memory serves, >> she was concerned >> > > about two locations in the Directory for the same >> information. The >> > > paragrah that you quote is Jim Schaad's proposed >> solution: Get the certs >> > > from userCertificates and the algorithm preference information >> > > userSMimeCertificate. >> > > >> > > Russ >> > > >> > > >> > > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote: >> > > >> > > >Russ, >> > > > >> > > >Certdist-04 section 4.5 explains: >> > > > >> > > > "If the SignedData object is to be published in >> userSMimeCertificate, >> > > > the end-entity certificates MAY be omitted from the >> certificate bag >> > > > and published in the userCertificates [sic] LDAP >> attribute instead." >> > > > >> > > >How is an application developer supposed to interpret >> this requirement? >> > > >I would read it to say that since the EE cert MAY be in >> either attribute, >> > > >applications MUST look for it in BOTH attributes. But >> Terry Hayes' >> > > >posting indicates that (without an add-on) Communicator >> does not look >> > > >in the userCertificate attribute. >> > > > >> > > >Section 2 justifies the inclusion of a cert path in the >> SignedData >> > > >object by claiming that in non-X.500 (DAP or LDAP) >> directories it is >> > > >difficult to impossible to obtain CA certificates. But >> it does not >> > > >follow through with that logic by *not* requiring a full >> cert path when >> > > >the object *is* stored in an LDAP directory. >> > > > >> > > >Section 4.3 should be changed from: >> > > > >> > > > "A chain of certificate from the >> end-entitycertificate(s) to the root >> > > > certificate(s) MUST be included in the CertificateSet." >> > > > >> > > >to: >> > > > >> > > > "A chain of certificate from the >> end-entitycertificate(s) to the root >> > > > certificate(s) MUST be included in the CertificateSet >> unless the >> > > > SignedData object is published in >> userSMimeCertificate, in which case >> > > > the CertificateSet MUST be empty." >> > > > >> > > >and section 4.5 should be adjusted accordingly. >> > > > >> > > >This would ensure that when using LDAP, applications >> always use the >> > > >PKIX-standard locations for both CA and EE certificates. >> > > > >> > > >Dave Kemp >> > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From owner-ietf-smime Wed Apr 12 13:23:54 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA18202 for ietf-smime-bks; Wed, 12 Apr 2000 13:23:54 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18198; Wed, 12 Apr 2000 13:23:53 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Apr 2000 16:27:03 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31965D63@wfhqex01.wangfed.com> From: "Pawling, John" To: "'SMIME WG'" , ietf-pkix@imc.org Subject: SNACC ASN.1 Freeware Release & Mail List Date: Wed, 12 Apr 2000 16:27:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has delivered an enhanced version of the freeware SNACC v1.3 rev 0.07 Abstract Syntax Notation.1 (ASN.1) Compiler and Library. In past releases, VDA enhanced the C++ version of the SNACC library to implement the Distinguished Encoding Rules (DER). In the new release, VDA enhanced the C and C++ versions of the SNACC library to support PrintableString, TeletexString, NumericString, IA5String, VisibileString, BMPString, UniversalString and UTF8String character string types. We added an optional function to SNACC that can be used to convert ASN.1 OCTET STRINGs to single- or multi-byte character strings (as appropriate). This is needed to support the RFC 2459 PKIX requirements. The SNACC enhancement is completely optional and does not impact existing code that uses SNACC. The SNACC library decodes an object as it always has. If the application/library needs the ASN.1 OCTET STRINGs converted to character strings, then it calls the new SNACC function/class to perform the conversion. If an application/library does not need the ASN.1 OCTET STRINGs converted, then it does not need to call the conversion function/classes and can use the SNACC-generated structures/classes as always. The VDA-enhanced SNACC compiler and C++ library is available along with the S/MIME Freeware Library (SFL) that uses SNACC to implement the S/MIME v3 set of specifications. The snacc1_6VDA.zip file contains the SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library source code compilable for Unix and MS Windows NT/95/98/2000. The VDA-enhanced SNACC C library is available along with the freeware Certificate Management Library (CML) that uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459. The CML17sr.tar.Z file includes the source code for the CML and VDA-enhanced SNACC C library compilable for Unix and MS Windows NT/95/98/2000. We plan to consolidate the enhancements made by VDA to the C and C++ versions of the SNACC source code into a single baseline that can be delivered in a single tar/zip file. In the new release, we also corrected a bug in the DEC_LOAD_ANYBUF macro. We changed "bytesDecoded" to "bytesDecodedXX" to avoid conflict other SNACC uses of the "bytesDecoded" variable. We also enhanced the AsnOid method so that it accepts a dynamic number of components within an object identifier. SNACC implements the majority of ASN.1 encoding/decoding rules. SNACC does not support all of the latest ASN.1 features, but there are work-arounds that allow SNACC to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be directly compiled using SNACC. The SNACC ASN.1 library is totally unencumbered as stated in the SFL Public License. All source code for the VDA-enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the VDA-enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established a SNACC web page . The IMC has also established a SNACC mail list which is used to: distribute information regarding SNACC releases; discuss SNACC-related issues; and provide a means for SNACC users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. VDA welcomes all feedback regarding the VDA-enhanced SNACC software. If bugs are reported, then VDA will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. We recommend that comments should be sent to the imc-snacc mail list. We will respond to all messages on that list. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-ietf-smime Wed Apr 12 13:15:10 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17843 for ietf-smime-bks; Wed, 12 Apr 2000 13:15:10 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17839 for ; Wed, 12 Apr 2000 13:15:09 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Apr 2000 16:18:19 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31965D57@wfhqex01.wangfed.com> From: "Pawling, John" To: "'SMIME WG'" Subject: v1.6 S/MIME Freeware Library & Mail List Date: Wed, 12 Apr 2000 16:18:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has delivered Version 1.6 of the S/MIME Freeware Library (SFL) source code and Application Programming Interface (API). The SFL source code files are freely available to everyone from the Fortezza Developer's S/MIME Page . The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H, 3DES) provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by the RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The SFL uses the VDA-enhanced SNACC v1.3 ASN.1 C++ Library to encode/decode objects. The v1.6 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); VDA- enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library; test utilities; test drivers and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Solaris 2.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X S/MIME v2 products. Signed messages have been exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 2630, 2631 and 2634. This testing included the RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We have also performed limited S/MIME v3 testing with Baltimore and Entrust. The following enhancements are included in the v1.6 SFL release (compared with the v1.5 release): 1) We used the SFL to successfully process all of the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to construct sample data (such as signed receipts) to be added to the document. We automated this SFL testing (through the use of test drivers and configuration files) so that it can be easily repeated and modified by us or independently by a third party. We developed sample objects that illustrate each feature in the Examples document that the SFL supports. This self-contained environment uses the specified certificates (DSA, RSA, and DH) in the login as described in the document. This directory resides in "./smimeR1.6/test/specMatrix.d/CMS_Examples.d"; the binaries are named as in the document (e.g. 5.4.bin, etc.). The config files used to generate these examples are in the "config.d" subdirectory. The certificate build config files are in the "certs.d/config.d" subdirectory. 2) We successfully completed RFC 2634 signed receipt interoperability testing between the SFL and Microsoft. We added a check to the SFL to ensure that the application always includes in the receiptRequest attribute a receiptsTo e-mail address to which the signed receipt is to be sent. 3) We verified that the SFL can produce and process the SFL-supported features documented in the S/MIME v3 interoperability matrices created by Jim Schaad. We automated this SFL testing so that it can be easily repeated and modified by us or independently by a third party. We have developed sample objects that illustrate each feature in the matrix that the SFL supports. We updated the Interop.xls document (contained in the "./smimeR1.6/test/specMatrix.d" subdirectories) to indicate the testing performed using the SFL. Within this document, each feature row contains a reference to a binary file in the "CMS_Examples.d" directory that demonstrates that feature if applicable. These additional file names are preceded by the name "ExInterop..." to distinguish them from the "examples-03.txt" example binaries. 4) Fixed a number of bugs in the SFL and test drivers found during the aforementioned interoperability testing. Features improved in the SFL include: proper SignedData and SignerInfo version numbers; creating/processing encrypted messages without a User Key Material (UKM); added SubjectKeyIdentifier (SKI) processing in SignedData and EnvelopedData (Originator only, the RecipientInfos automatically use SKI for Fortezza/SPEX CTILs); and EnvelopedData unprotectedAttrs from the test config file. We also corrected the following bugs in the test driver/configuration files used to create X.509 Certificates for SFL testing: corrected inconsistent UTC and General Time Dates; included dates past 1999; corrected object identifiers (OID) for algorithms; and regenerated certificates to include unsigned integers. 5) List template processing has been fixed to use the same "CSM_ListC" template from the common libCert DLL. The old convention required a new name for this list class in each DLL; the new convention uses the same CSM_ListC template class from libCert. This forces the compiler to build the logic for the actual class lists uniquely in the new DLL (see references to CSM_ListC in the SFL for an example). This simplifies the list logic in support libraries and any new user libraries interested in using the list template. 6) CertificateBuilder utility has been improved in functionality and tested more thoroughly. This utility can view, edit, and create certificates (including extensions) as well as generate a variety of public/private keys for processing by the SFL. A new command line CertificateBuilderCL has been created (it does not yet allow the building of keys, private or public). The command line utility has not yet been tested on Unix. 7) Tested SFL with the C++ version of the SNACC ASN.1 library enhanced to support PrintableString, TeletexString, NumericString, IA5String, VisibileString, BMPString, UniversalString and UTF8String character string types. We added an optional function to SNACC to convert ASN.1 OCTET STRINGs to single- or multi-byte character strings (as appropriate). 8) Developed new test code and configuration files to implement test cases; and 9) Performed regression testing to ensure that aforementioned enhancements did not break existing SFL functionality. We are still in the process of enhancing and testing the SFL. Future releases will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line utility; enhancing CertificateBuilder to support creation of Attribute Certificates; modify PKCS #12 code in test utilities to provide interoperable key storage; add MIME support for test drivers; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; support for other crypto APIs (possible); and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows and Solaris 2.7, we plan to port the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 (possibly), SCO 5.0 (possibly) and Macintosh (possibly). The following SFL files are available from the Fortezza Developer's S/MIME Page: 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) snacc1_6VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library source code compilable for Unix and MS Windows NT/95/98/2000 that has been enhanced by VDA to implement the Distinguished Encoding Rules and to support multiple-byte character strings. Project files and makefiles are included. This file includes a sample test project demonstrating the use of the SNACC classes. 3) smimeR16.zip: Zip file containing all SFL source code including: SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source code; project files. This file also contains test driver source code, sample CMS/ESS test data and test X.509 Certificates. This file also includes test utilities to create X.509 Certificates that each include a D-H, DSA or RSA public key. SNACC release and debug libraries are compiled for MS Windows NT/95/98/2000. MS Windows NT/95/98/2000 project files and Unix makefiles are included for the SNACC code and Crypto++. 4) smR16CTI.zip: Source code for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11. The Win95/98/NT/2000 projects are also included. (NOTE: The Free (a.k.a. Crypto++) CTIL includes VDA-developed source code to use the RSA public key algorithm implemented within the external Crypto++ library. As with all of the external crypto token libraries, the Crypto++ library is not distributed as part of the SFL source code. To use the Crypto++ library with the SFL, the application developer must independently obtain the Crypto++ library from the Crypto++ Web Page and then compile it with the VDA-developed Crypto++ CTIL source code. The RSA public key algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication System and Method". Within the U.S., users of the RSA public key algorithm provided by the external Crypto++ library must obtain a license from RSA granting them permission to use the RSA algorithm.) 5) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. VDA is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License" available from the VDA SFL Page and Fortezza Developer's S/MIME Page. On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. For example, the SFL uses the freeware Crypto++ library to obtain 3DES, D-H and DSA. To use the SFL with Crypto++ the vendor must download the Crypto++ freeware library from the Crypto++ Web Page and then compile it with the VDA-developed Crypto++ CTIL source code. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. We recommend that comments should be sent to the imc-sfl mail list. We will respond to all messages on that list. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-ietf-smime Thu Apr 13 05:52:43 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA19947 for ietf-smime-bks; Thu, 13 Apr 2000 05:52:43 -0700 (PDT) Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19942 for ; Thu, 13 Apr 2000 05:52:42 -0700 (PDT) Received: by MARS with Internet Mail Service (5.5.2650.21) id <2JTDM9CY>; Thu, 13 Apr 2000 08:56:09 -0400 Message-ID: From: Aram Perez To: ietf-smime@imc.org Subject: RE: CERTDIST Date: Thu, 13 Apr 2000 08:56:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Mike Just [mailto:mike.just@entrust.com] > Sent: Wednesday, April 12, 2000 11:47 AM > To: ietf-smime@imc.org > Cc: 'dpkemp@missi.ncsc.mil'; 'Russ Housley' > Subject: RE: CERTDIST > > > Two points. > > 1) I agree with David. The document must be clear that if > using LDAP, user > certificates should be in the userCertificate attribute; user > certificates > MUST NOT be in the userSMimeCertificate attribute. (In other words, > userSMimeCertificate is only used as a source of a user's S/MIME > capabilities.) I also agree, but shouldn't that field be called userSMimeCapabilities? userSMimeCertificate implies that it stores a certificate. Regards, Aram Perez [snip] From owner-ietf-smime Thu Apr 13 06:44:40 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20710 for ietf-smime-bks; Thu, 13 Apr 2000 06:44:40 -0700 (PDT) Received: from gate.ritlabs.com (IDENT:root@gw-ritlabs.mldnet.com [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20705; Thu, 13 Apr 2000 06:44:25 -0700 (PDT) Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id QAA01818; Thu, 13 Apr 2000 16:50:24 +0300 Date: Thu, 13 Apr 2000 16:47:40 +0300 From: Maxim Masiutin X-Mailer: The Bat! (v1.42 Beta/17) Organization: RIT Research Labs X-Priority: 3 (Normal) Message-ID: <105192921875.20000413164740@ritlabs.com> To: ietf-pkix@imc.org, ietf-smime@imc.org Subject: duplicate aliases of the same OID in draft-ietf-pkix-new-part1-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello! I've found duplicate aliases of the same OID in draft-ietf-pkix-new-part1-01.txt sha-1WithRSAEncryption (section 7.2.1) and sha1WithRSAEncryption (elsewhere). The first variant was also found in rfc2632, rfc2633 (along with the second variant). Second variant was also found in draft-ietf-smime-certdist-04.txt, draft-ietf-smime-examples-03.txt and rfc2633. There are also numerous duplicate OID aliases, for example PKCS#9-relaeted; they are different in PKIX documents, S/MIME documents and PKCS#9 itself. I've found it writing my ASN.1 code to work with S/MIME messages and X.509 certificates. Having multiple names of a same OIDS is much worse than having one, I think both workgroups should take care of that. -- Maxim Masiutin, Software Engineer RIT Research Labs http://www.ritlabs.com/ From owner-ietf-smime Thu Apr 13 07:22:23 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21692 for ietf-smime-bks; Thu, 13 Apr 2000 07:22:23 -0700 (PDT) Received: from gate.ritlabs.com (IDENT:root@gw-ritlabs.mldnet.com [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21688; Thu, 13 Apr 2000 07:22:15 -0700 (PDT) Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id RAA24796; Thu, 13 Apr 2000 17:28:34 +0300 Date: Thu, 13 Apr 2000 17:25:51 +0300 From: Maxim Masiutin X-Mailer: The Bat! (v1.42 Beta/17) Organization: RIT Research Labs X-Priority: 3 (Normal) Message-ID: <169195212875.20000413172551@ritlabs.com> To: ietf-pkix@imc.org, ietf-smime@imc.org Subject: id-ct-compressedData vs id-ct-publishCert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello! id-ct-compressedData from draft-ietf-smime-compression-00.txt and id-ct-publishCert from draft-ietf-smime-certdist-04.txt has same OID In draft-ietf-smime-compression-00.txt, it is defined as iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 3 In draft-ietf-smime-certdist-04.txt, it is defined as iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 3 which is same. I've found it confusing; I would like go get a solution from the authors of drafts above mentioned. -- Maxim Masiutin, Software Engineer RIT Research Labs http://www.ritlabs.com/ From owner-ietf-smime Fri Apr 14 03:33:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA23982 for ietf-smime-bks; Fri, 14 Apr 2000 03:33:49 -0700 (PDT) Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA23977 for ; Fri, 14 Apr 2000 03:33:47 -0700 (PDT) Received: (qmail 23597 invoked from network); 14 Apr 2000 10:37:30 -0000 Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 14 Apr 2000 10:37:30 -0000 Received: (qmail 15584 invoked from network); 14 Apr 2000 10:37:29 -0000 Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 14 Apr 2000 10:37:29 -0000 From: "William Ottaway" To: , "IETF SMIME List" Subject: RE: Domain-to-point security services & DOMSEC Date: Fri, 14 Apr 2000 11:37:10 +0100 Message-ID: <000601bfa5fd$636f2300$110a6280@wottaway.eris.dera.gov.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <38F33394.CB5A17F8@verkstad.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Luis, I believe the scenario you describe is handled in a DOMSEC environment. In fact this is exactly the type of scenario that drove us to produce the DOMSEC ID. Section 4 of DOMSEC describes a domain and/or an individual being able to encrypt for a recipient or the recipient's domain (DCA - Domain Confidentiality Authority): - "Messages may be encrypted for decryption by the final recipient and/or by a DCA in the recipient's domain." In your scenario the originator would send a message to the intended recipient as usual but the originator or the originator's domain encrypts the message so that the recipients domain (DCA) can decrypt it. We think this is covered by section 4: * Section 4.1 describes a naming convention that must be followed so that the certificate for the recipient's domain can be identified. * Section 4.3 describes how a DCA decrypts a message that has been encrypted by an originator and/or an originator's domain. After re-reading this section we have changed it slightly to aid clarity, and (hopefully!) to make it more clear that we are covering the scenario you describe: -- Begin new section 4.3 "4.3 Key Management for Domain Decryption Domain decryption uses a domain-wide decryption key from the recipient's domain. This key is owned by the DCA for the recipient domain. In order for an encrypting process to locate the correct key, the certificate corresponding to the DCA in the recipient's domain must be located. This is achieved using the naming conventions specified in 4.1. It is vital that these conventions are adhered to, in order to maintain confidentiality. It should be noted that domain decryption can be performed on messages encrypted by the originator and/or by a DCA in the originator's domain. In the first case, the encryption process is described in CMS [5]; in the second case, the encryption process is described in 4.2. No specific method for locating this certificate is mandated in this document. An implementation may choose to access a local certificate store to locate the correct certificate. Alternatively, a directory may be used in one of the following ways: 1. The directory may store the DCA certificate in the recipient's directory entry. When the user certificate attribute is requested, this certificate is returned. 2. The encrypting agent maps the recipient's name to the DCA name in the manner specified in 4.1. The user certificate attribute associated with this directory entry is then obtained. This document does not mandate either of these processes. Whichever one is used, the name mapping conventions must be adhered to, in order to maintain confidentiality. Having located the correct certificate, the encryption process is then performed. A recipientInfo for the DCA is then generated, as described in CMS [5]." -- End new section 4.3 We see DOMSEC as a means of describing the building blocks required to provide secure messaging between individuals and domains using S/MIME. How these blocks are integrated into real systems is very much a policy matter and consequently we do not go into this realm within DOMSEC. To summarise, we believe your scenario is covered by DOMSEC. Do you agree? Is further clarification needed? If so where? Bill. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Luis Barriga > Sent: 11 April 2000 15:16 > To: IETF SMIME List > Subject: Domain-to-point security services & DOMSEC > > > I have a common scenario that I believe should be addressed within this > group. I'll refer to it as domain-to-point secure messaging and it looks > as follows: > > A user A@ISP.com wishes to communicate *securely* with a another user > B@Company.com. The user B@Company.com doesn't have a cert (or if he does > A@ISP.com doesn't know it). I see this as a common case, when companies > start migrating to PKI and: > > (1) A@ISP.com is actually a user A@Company.com, who has temporarily left > his corporate premises and has a public email account at an POP/IMAP > service provider. A wants to exchange email securely with colleagues at > the Company, but not all of them have certs. > > (2) A@ISP.com is an external user with no association with > Corporate.Com, but who wants to send important secure email to > B@Company.com. A@ISP.com can't access the Company's PKI. > > To solve this, the Company can deploy a domain securiy service, sort of > S/MIME proxy with public cert associated with Smime-proxy@Company.com. > The user A@ISP.com (the point) could then send S/MIME to this proxy (the > domain) with request to forward the email to the end user B@Company.com. > If A also has a cert, then B can reply securely directly or via the > S/MIME proxy, provided that the proxy has access to the A's PKI > (Company.Com or ISP.com). > > BTW, this scheme also allows users to store corporate email on > unstrusted public POP/IMAP services providers. It can also be used for > secure mailing lists and cert distribution. > > My question to You folks is: > > 1. Is there enough interest out there to work towards a draft? > > 2. It seems that this falls within the DOMSEC draft, but the scenario > above is not explicitly addressed. Any opinion on this? > > 3. Anybody else done something similar? > > ------ > Luis Barriga > Ericsson Research > From owner-ietf-smime Fri Apr 14 08:19:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29917 for ietf-smime-bks; Fri, 14 Apr 2000 08:19:05 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29913 for ; Fri, 14 Apr 2000 08:19:00 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA13315 for ; Sat, 15 Apr 2000 03:22:40 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95572576004216>; Sat, 15 Apr 2000 03:22:40 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Re: id-ct-compressedData vs id-ct-publishCert Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 15 Apr 2000 03:22:40 (NZST) Message-ID: <95572576004216@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maxim Masiutin writes: > id-ct-compressedData from draft-ietf-smime-compression-00.txt and > id-ct-publishCert from draft-ietf-smime-certdist-04.txt has same OID I posted a comment on this here a fortnight ago (in fact it was in reply to a message from you), the id-ct-compressedData value was chosen when there was nothing else occupying that slot, it's now: id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7 } (which was free as of the time of the previous posting). Peter. From owner-ietf-smime Fri Apr 14 15:31:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA06967 for ietf-smime-bks; Fri, 14 Apr 2000 15:31:17 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06963 for ; Fri, 14 Apr 2000 15:31:16 -0700 (PDT) Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id PAA28123 for ; Fri, 14 Apr 2000 15:35:06 -0700 (PDT) From: "Jim Schaad" Reply-to: jimsch@nwlink.com To: ietf-smime@imc.org Date: Fri, 14 Apr 2000 15:35:06 +0800 Subject: draft-ietf-smime-idea-03 Message-id: <38f79d1a.7668.0@nwlink.com> X-User-Info: 203.108.193.31 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The S/MIME Capability sequences appear to be wrong. In section 4 paragraph 2, the text states that the parameters field must be absent, however the encoding sequence given has the parameters encoded as NULL. The same is true in paragraph 3 of the same section. jim http://www.nwlink.com From owner-ietf-smime Fri Apr 14 16:00:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07382 for ietf-smime-bks; Fri, 14 Apr 2000 16:00:30 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA07378 for ; Fri, 14 Apr 2000 16:00:29 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 14 Apr 00 16:03:49 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Apr 2000 16:03:49 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C594FB4F@mail.deming.com> From: "Blake Ramsdell" To: "'jimsch@nwlink.com'" , ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 Date: Fri, 14 Apr 2000 16:03:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 14E97C5F83985-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agree. I think this should be 300D at the beginning, and trim the last two bytes off of both examples. Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, April 14, 2000 12:35 AM To: ietf-smime@imc.org Subject: draft-ietf-smime-idea-03 The S/MIME Capability sequences appear to be wrong. In section 4 paragraph 2, the text states that the parameters field must be absent, however the encoding sequence given has the parameters encoded as NULL. The same is true in paragraph 3 of the same section. jim http://www.nwlink.com From owner-ietf-smime Sun Apr 16 21:14:37 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA19811 for ietf-smime-bks; Sun, 16 Apr 2000 21:14:37 -0700 (PDT) Received: from www.pressmedia.com.pl ([195.117.30.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19807 for ; Sun, 16 Apr 2000 21:14:35 -0700 (PDT) Message-Id: <200004170414.VAA19807@ns.secondary.com> Received: from kllklk (ip217.providence11.ri.pub-ip.psi.net [38.26.242.217]) by www.pressmedia.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 28K9CBBJ; Mon, 17 Apr 2000 06:18:00 +0200 From: "Harry Trent" Subject: Investment Marketing is Here! To: invest28d X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 16 Apr 2000 23:37:00 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA19808 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Use Investment Marketing to promote whatever investment ideas you have to increase stock growth. Investment Marketing uses mailings to get your ideas out there to the people who want to read them and USE them for capital gains. Our extensive lists of quality leads are compiled of people who have asked to receive mail. We use only state-of-the-art promotional software and do all of the work for you. You won't need any special software or hardware. Just send us your advertisement or HOT INVESTMENT TIP and we will send you an e-mail with the time and date when the marketing mail will be sent. Then you just keep a close eye on the stock you picked and watch it GROW! Please call 401-433-5811 for more information and our rates. Thank you, Investment Marketing Specialists ///////////////////////////////////////////////////////////////////// /// Please remove at: mailto:brir7@netscape.net?subject=remove ///////////////////////////////////////////////////////////////////// /// From owner-ietf-smime Mon Apr 17 07:45:57 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA02965 for ietf-smime-bks; Mon, 17 Apr 2000 07:45:57 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02959 for ; Mon, 17 Apr 2000 07:45:52 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id QAA24956; Mon, 17 Apr 2000 16:45:37 +0200 (MET DST) Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA09597; Mon, 17 Apr 2000 16:45:35 +0200 Message-ID: <38FB23C7.F61925E0@ericsson.com> Date: Mon, 17 Apr 2000 16:46:31 +0200 From: Luis Barriga Reply-To: Luis.Barriga@era-t.ericsson.se Organization: Ericsson Radio Systems X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF SMIME List CC: William Ottaway Subject: Re: Domain-to-point security services & DOMSEC References: <000601bfa5fd$636f2300$110a6280@wottaway.eris.dera.gov.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bill, DOMSEC covers partially the requirements I described. Below, I explain why and at the end I list where DOMSEC should be updated to fully address all requirements. DOMSEC addresses the case when an individual encrypts for a recipient's domain and the DCA decrypts. I call this case point2domain requirement. What I think is missing is the domain2point requirement. In this case the domain Company.Com needs to send secure mail to one of its members A@Company.Com, who is on the Internet reachable as A@ISP.Com. Note that ISP.Com is considered an unstrusted domain from the Company's perspective. The DOMSEC draft has a very generic phrase "Messages may be encrypted for decryption by the final recipient and/or by a DCA in the recipient's domain". This seems to cover both point2domain and domain2point, but it actually handles in detail only point2domain. What I would like to see an explicit domain2point requirement, with a more clear description how this is achieved. What I'm aiming at is that the email from an intranet user sender@Company.Com would be encrypted by the DCA for a recipient A@Company.Com on behalf of the sender *using the recipient's A@Company.Com cert*. Optionally the DCA would put a domain signature. The resulting SMIME object would then be sent to A@ISP.Com. A mismatch between A@ISP.Com and A@Company.Com has to be solved. The following sections should be extended: o Abstract - focuses on domain interoperation. Should consider domain2point. 1. Introduction - there are 4 issues named and the 3rd one is about PKI deployment issues for certification paths between organizations. The domain2point requirement is not named. The issue here is that the sender on the Intranet can't PKI/SMIME or there is a security policy restricting it. 2.4 Domain Encryption and Decryption - The definition of domain encryption excludes the domain2point case, because it assumes a domain2domain or point2domain scenario. Domain encryption should be defined to also include the case of encryption on behalf of a sender *using the recipient's cert*. 4. Encryption and Decryption - still focused on point2domain. Should consider domain2point. 4.2 Key Management for Domain Encryption - The key used here is a domain key which is ok for point2domain. This section should also consider domain2point where the encryption key is the recipient's key. 4.3. Key Management for Domain Decryption - This section has been written to complete 4.2. A small caveat should probably be needed to say that no domain decryption applies for domain2point. -------- Luis Barriga Ericsson Reseach William Ottaway wrote: > > Hi Luis, > > I believe the scenario you describe is handled in a DOMSEC environment. In > fact this is exactly the type of scenario that drove us to produce the > DOMSEC ID. > > Section 4 of DOMSEC describes a domain and/or an individual being able to > encrypt for a recipient or the recipient's domain (DCA - Domain > Confidentiality Authority): - > > "Messages may be encrypted for decryption by the final recipient and/or by a > DCA in the recipient's domain." > > In your scenario the originator would send a message to the intended > recipient as usual but the originator or the originator's domain encrypts > the message so that the recipients domain (DCA) can decrypt it. We think > this is covered by section 4: > > * Section 4.1 describes a naming convention that must be followed so that > the certificate for the recipient's domain can be identified. > > * Section 4.3 describes how a DCA decrypts a message that has been encrypted > by an originator and/or an originator's domain. > > After re-reading this section we have changed it slightly to aid clarity, > and (hopefully!) to make it more clear that we are covering the scenario you > describe: > > -- Begin new section 4.3 > > "4.3 Key Management for Domain Decryption > > Domain decryption uses a domain-wide decryption key from the recipient's > domain. This key is owned by the DCA for the recipient domain. In order for > an encrypting process to locate the correct key, the certificate > corresponding to the DCA in the recipient's domain must be located. This is > achieved using the naming conventions specified in 4.1. It is vital that > these conventions are adhered to, in order to maintain confidentiality. > > It should be noted that domain decryption can be performed on messages > encrypted by the originator and/or by a DCA in the originator's domain. > In the first case, the encryption process is described in CMS [5]; in the > second case, the encryption process is described in 4.2. > > No specific method for locating this certificate is mandated in this > document. An implementation may choose to access a local certificate store > to locate the correct certificate. Alternatively, a directory may be used in > one of the following ways: > > 1. The directory may store the DCA certificate in the recipient's directory > entry. When the user certificate attribute is requested, this certificate is > returned. > > 2. The encrypting agent maps the recipient's name to the DCA name in the > manner specified in 4.1. The user certificate attribute associated with this > directory entry is then obtained. > > This document does not mandate either of these processes. Whichever one is > used, the name mapping conventions must be adhered to, in order to maintain > confidentiality. > > Having located the correct certificate, the encryption process is then > performed. A recipientInfo for the DCA is then generated, as described in > CMS [5]." > > -- End new section 4.3 > > We see DOMSEC as a means of describing the building blocks required to > provide secure messaging between individuals and domains using S/MIME. How > these blocks are integrated into real systems is very much a policy matter > and consequently we do not go into this realm within DOMSEC. > > To summarise, we believe your scenario is covered by DOMSEC. Do you agree? > Is further clarification needed? If so where? > > Bill. > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Luis Barriga > > Sent: 11 April 2000 15:16 > > To: IETF SMIME List > > Subject: Domain-to-point security services & DOMSEC > > > > > > I have a common scenario that I believe should be addressed within this > > group. I'll refer to it as domain-to-point secure messaging and it looks > > as follows: > > > > A user A@ISP.com wishes to communicate *securely* with a another user > > B@Company.com. The user B@Company.com doesn't have a cert (or if he does > > A@ISP.com doesn't know it). I see this as a common case, when companies > > start migrating to PKI and: > > > > (1) A@ISP.com is actually a user A@Company.com, who has temporarily left > > his corporate premises and has a public email account at an POP/IMAP > > service provider. A wants to exchange email securely with colleagues at > > the Company, but not all of them have certs. > > > > (2) A@ISP.com is an external user with no association with > > Corporate.Com, but who wants to send important secure email to > > B@Company.com. A@ISP.com can't access the Company's PKI. > > > > To solve this, the Company can deploy a domain securiy service, sort of > > S/MIME proxy with public cert associated with Smime-proxy@Company.com. > > The user A@ISP.com (the point) could then send S/MIME to this proxy (the > > domain) with request to forward the email to the end user B@Company.com. > > If A also has a cert, then B can reply securely directly or via the > > S/MIME proxy, provided that the proxy has access to the A's PKI > > (Company.Com or ISP.com). > > > > BTW, this scheme also allows users to store corporate email on > > unstrusted public POP/IMAP services providers. It can also be used for > > secure mailing lists and cert distribution. > > > > My question to You folks is: > > > > 1. Is there enough interest out there to work towards a draft? > > > > 2. It seems that this falls within the DOMSEC draft, but the scenario > > above is not explicitly addressed. Any opinion on this? > > > > 3. Anybody else done something similar? > > > > ------ > > Luis Barriga > > Ericsson Research > > From owner-ietf-smime Mon Apr 17 20:40:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA05317 for ietf-smime-bks; Mon, 17 Apr 2000 20:40:30 -0700 (PDT) Received: from zeus.anet-chi.com (root@zeus.anet-chi.com [207.7.4.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05312 for ; Mon, 17 Apr 2000 20:40:29 -0700 (PDT) Received: from anet.com (as1-96.chi.il.dial.anet.com [198.92.156.96]) by zeus.anet-chi.com (8.9.3/spamfix) with ESMTP id WAA23936; Mon, 17 Apr 2000 22:44:20 -0500 (CDT) Message-ID: <38FBD9BB.A3A02127@anet.com> Date: Mon, 17 Apr 2000 22:42:52 -0500 From: Nicolls X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: jimsch@nwlink.com CC: ietf-smime@imc.org Subject: Re: Comments on SecLabel draft References: <38e20272.3756.0@nwlink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim Thanks for your comments and questions. My responses are below >> Jim Schaad wrote: > SecLabel > > 1. Section 1 P2 - Security labels cannot be bound to an encrypted body, only > to a signed message. > >> Yes. Will reword to state that they may be included in the signed attributes > of any > SignedData object. > 2. Please give more text explaining the difference between rank and role based > security. From the current description they look like the same to me. > >> Yes, more explaination is needed. The main different is that rank based AC is > hierarchical while role based is not necessarily (which isnt what I wrote). > Roles can be defined without regard to a hierarchy. Better examples of roles > such as DB Administrator or Network Admin and Shipper Purchaser, which do not > imply a hierarchy but can have their own set of information that only holders of > that role may have access. Another way of explaining the difference can be that > Rank based AC is based on who you are while Role based AC is based on what you > do. > 3. The Amoco policy description is not clear. From the text I assumed that > the confidentiality and integrity were orthogonal axis for make decisions (thus > leading to 9 items). Based on the conversation with you this is not true as > the policy is choose one of the axis and then the point on the axis. The text > should be clarified as to which is correct. > >> Yes, the confidentiality and integrity polices are independent so either or > both may be chosen. I'll add wording to 2.1.1. I think it is also appropriate > to remove the integrity policy values from the security classification section > (2.2.1.2) and clearance section (2.2.2). Integrity does not effect access > control. It belongs in the privacy mark section, if anywhere. > 4. Typo - Section 1.2 last para - "while he outer signature" should be "while > the". >> Yes. > 5. Section 2.2.1.3 -- I don't think that one should provide a syntax for the > privacy marks. However giving a couple of the privacy marks or guidelines from > the policy on writting them might be useful. Given that a privacy mark is a > UTF8 string in the syntax, no addtional ASN syntax is really possible. > >> Agree. Will see about on examples or guidelines. > > 6. You say that categories are used informally, however without knowning how > they would be used or specified I cannot even hope to offer syntax suggestions. > Given that they are informal why would they not be marked as privacy labels. > If they are categories then I would expect the policy module to do enforcement > thus being informal would cause some difficulties. >> I meant that categories are not formally defined in the information security policies but are used in the organization. Project or organizations do define their own category to limit access to data to members of an organization or a project. Once defined, then they are formal and are to be enforced >> So the owner of the classification policy allows departments to define security categories that are bound to the classification policy. A category "HR Department" could be defined under the Company ABC classification policy OID and CompanyABC-SecurityCategory (1) could become "HR Department Only". Then CompanyABC-Project NextGreatestWasher could become bound to category (2) and so on. The hard part being how the application knows what categories are being used and what to display to the user. >> As far as a syntax, would a new OID need to be defined for each category? Does the syntax just need to provide the application with the text to display to the user? > 7. I suggest that you name Clearance in the ASN sections to be XxxxSection. > a nd the same for the other top level items. > >> Will fix numbering for section 2.2.2. >> Weston From owner-ietf-smime Wed May 3 15:53:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15692 for ietf-smime-bks; Wed, 3 May 2000 15:53:03 -0700 (PDT) Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15683 for ; Wed, 3 May 2000 15:53:01 -0700 (PDT) From: rrlist@bigfoot.com Received: from tot-tj.proxy.aol.com (tot-tj.proxy.aol.com [152.163.213.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id QAA22423 for ; Wed, 3 May 2000 16:52:35 -0400 (EDT) Received: from client (98A876B0.ipt.aol.com [152.168.118.176]) by tot-tj.proxy.aol.com (8.10.0/8.10.0) with SMTP id e43KqXu19290 for ietf-smime@imc.org; Wed, 3 May 2000 16:52:33 -0400 (EDT) Date: Wed, 3 May 2000 16:52:33 -0400 (EDT) Message-Id: <200005032052.e43KqXu19290@tot-tj.proxy.aol.com> To: Subject: 50 Megs of web space for $9.95 a month! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 50 Megs of web space for $9.95 a month!!!! Unlimited E-Mail boxes at yourdomain.com and much more! We offer web hosting in a number of different packages. Tired of paying alot for web hosting and not recieving quality customer service? Try out our hosting services, and see the difference of a web hosting company run by computer technicians. Call 1-888-682-5214 for more information. Ask about our dedicated servers and reseller package. $99.95 a month Colo and Dedicated Servers. To be removed from this list reply to rrlist@bigfoot.com with the header of Delete From owner-ietf-smime Sat May 6 14:27:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA12009 for ietf-smime-bks; Sat, 6 May 2000 14:27:41 -0700 (PDT) Received: from odin.kubtelecom.ru ([213.132.64.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12005 for ; Sat, 6 May 2000 14:27:40 -0700 (PDT) Received: from kllklk (01-033.044.popsite.net [216.126.163.33]) by odin.kubtelecom.ru (8.9.3/8.9.3/relay.domain) with ESMTP id BAA97867; Sun, 7 May 2000 01:33:01 +0400 (MSD) Message-Id: <200005062133.BAA97867@odin.kubtelecom.ru> From: "Rene Brir" Subject: You Can Win To: today2i@odin.kubtelecom.ru X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sat, 06 May 2000 16:49:56 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA12006 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you interested in increasing your odds in winning a lottery? To find out how, reply to: mailto:perr89@populus.net?subject=How_to_win We will only respond if all of the information below is completed. Thanks for your time. Name: _________________________________________ Email Address: __________________________________ Address __________________________________________ City ________________________ ST _____ ZIP __________ Phone (_______) ______________________Best time to call. ***************************************************************** This message is sent in compliance of the new email bill section 301. PerSection 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. ================================================================= If you wish to be removed from future mailings, please Reply to:mailto:stap92@usa.net?subject=remove From owner-ietf-smime Sun May 7 11:59:40 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07066 for ietf-smime-bks; Sun, 7 May 2000 11:59:40 -0700 (PDT) Received: from flamingo.mkpi.co.id ([202.155.24.179]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07062 for ; Sun, 7 May 2000 11:59:36 -0700 (PDT) Message-Id: <200005071859.LAA07062@ns.secondary.com> Received: from kllklk (01-033.044.popsite.net [216.126.163.33]) by flamingo.mkpi.co.id with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KFTDJL81; Mon, 8 May 2000 02:08:37 +0700 From: "Tony Meyer" Subject: Its A New World A New Economy To: new39s X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 07 May 2000 13:32:39 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA07063 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Today It’s Cell Phones and the Internet – What Is The Next Big Thing? Have you ever wondered why so many tech and e-business-related stocks just keep bouncing back or why many Internet businesses have billion-dollar market caps? Simply stated: the numbers are staggering. The market analysts and the smart money know that there is a huge amount of money to be made. It is conservatively estimated that in 2004 there will be over 7 Trillion dollars in Internet business-to-business transactions. This year there will be less than a quarter of a Trillion B2B transactions but even a quarter of a Trillion is a staggering sum. In three years the B2B market is expected to expand by over 28 times! The numbers are staggering! If you have a minimum of $25,000.00 to loan, short term; send an e-mail to us at: mailto:skf98@populus.net?subject=Biz_Plan requesting a copy of our business plan. To see it you must state in your e-mail that you are capable of comfortably loaning $25,000.00 in support of the right business plan. Prior to receiving our plan you will be required to sign a nondisclosure agreement. When you do you will discover that we have it right. The right contacts, products, vision, management and the right marketing plan all at the right time! You can be a part of the “Next Big Thing”! No more than ten people will have the chance to take advantage of this opportunity. They will receive 20% interest on their money and stock options with very lucrative possibilities. When you see our plan you will realize that investors will be standing in line to purchase the stock at private placement and/or IPO prices. Through the stock options we are offering ten or fewer visionary business partners will enjoy stock options at a price far below private placement or IPO prices. If you are serious and you can comfortably loan a minimum of $25,000.00 act now! Are you just curious? Please . . . Do not waste your time or ours if you do not have the investment credentials mentioned above PLEASE NOTE: Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to: mailto:kmmt@uymail.com?subject=remove You have received this offer because your email address is part of our "in House" list. You or someone you know has sent your email address to us in the past. Our team promotes professional and responsible use of email marketing. If this message is in error we apologize. From owner-ietf-smime Mon May 8 06:32:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16018 for ietf-smime-bks; Mon, 8 May 2000 06:32:02 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16009 for ; Mon, 8 May 2000 06:31:59 -0700 (PDT) Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA06309 for ; Mon, 8 May 2000 06:37:16 -0700 (PDT) Message-Id: <4.2.0.58.20000508092429.00a5c160@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 08 May 2000 09:36:38 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: S/MIME IDEA Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have just been made aware that the IDEA encryption algorithm has been posted on the "IETF Page of Intellectual Property Rights Notices" web site: http://www.ietf.org/ietf/IPR/ASCOM-IDEA Also, Stephan tells me that a new Internet-Draft will be posted in the next few days. Once it is posted, I will be calling for Working Group Last Call on this document. By the way, I have asked the authors to change the title. The new title will be: Use of the IDEA Encryption Algorithm in CMS Russ From owner-ietf-smime Mon May 8 07:34:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16854 for ietf-smime-bks; Mon, 8 May 2000 07:34:49 -0700 (PDT) Received: from fanniemae.com (ns1.fanniemae.com [198.204.134.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16850 for ; Mon, 8 May 2000 07:34:46 -0700 (PDT) Received: from psysadm-fw01bx.fanniemae.com (fw01b [198.204.133.71]) by fanniemae.com (8.9.1a/8.9.1) with SMTP id KAA04192 for ; Mon, 8 May 2000 10:40:03 -0400 (EDT) Received: from [158.137.199.163] by psysadm-fw01bx.fanniemae.com via smtpd (for [198.204.133.67]) with SMTP; 8 May 2000 14:40:02 UT Received: from 158.137.199.160 by fm-mailfw1.fanniemae.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Mon, 08 May 00 10:39:17 -0400 X-Server-Uuid: 988a06f2-702d-11d2-9ff4-0008c7a4c0f1 Received: from psysadm-em01.fanniemae.com by fanniemae.com ( SMI-8.6/SMI-SVR4) id KAA29100; Mon, 8 May 2000 10:40:00 -0400 Received: from fanniemae.com ([172.25.67.245]) by psysadm-em01.fanniemae.com (Netscape Messaging Server 4.05) with ESMTP id FU8WQO00.SDO for ; Mon, 8 May 2000 10:40:00 -0400 Message-ID: <3916D166.D13365B1@fanniemae.com> Date: Mon, 08 May 2000 10:38:31 -0400 From: "Nida Sun" Organization: Fannie Mae X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Subject: Delete References: <4.2.0.58.20000508092429.00a5c160@mail.spyrus.com> X-WSS-ID: 15080E1F47735-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-smime Mon May 8 13:46:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA22990 for ietf-smime-bks; Mon, 8 May 2000 13:46:11 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22986 for ; Mon, 8 May 2000 13:46:09 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 16:51:27 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31965F1C@wfhqex01.wangfed.com> From: "Pawling, John" To: "SMIME WG (E-mail)" Subject: Final 29 March 2000 S/MIME WG Minutes Date: Mon, 8 May 2000 16:51:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message includes the minutes of the IETF S/MIME Working Group meeting held on 29 March 2000 in Adelaide, Australia. All briefing slides will be stored at: ftp://ftp.ietf.org/ietf/smime/. These minutes include comments from the briefing presenters. Reported by John Pawling. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Introductions - Russ Housley Russ reviewed the agenda as follows. Nobody objected to the agenda. Introductions Russ Housley Working Group Status Russ Housley Security Policies and Labels Russ Housley CERTDIST Draft Discussion Jim Schaad Symmetric Key Distribution Sean Turner DOMSEC Draft Discussion Bill Ottaway Interoperability Matrix Jim Schaad CMS/ESS Examples Paul Hoffman Crypto Algorithm Documents Russ Housley E-mail Addresses & Certificates Greg Colla S/MIME Freeware Library John Pawling Electronic Signature Formats John Ross Wrap up Russ Housley +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Working Group Status - Russ Housley Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards: RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999 RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999 RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999 RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999 RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999 RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME. R. Zuccherato. March 2000. [Informational] The aforementioned documents must meet the following requirements to become Draft Standards: 1) Meet requirements documented in RFC 2026 2) Stable, mature, and useful specification 3) At least two independent and interoperable implementations from different code bases 4) Draft Standards cannot reference Proposed Standard RFCs or Experimental RFCs, so the aforementioned RFCs are blocked until the PKIX Certificate and CRL Profile "Son-of-RFC 2459" Internet-Draft (I-D) (draft-ietf-pkix-new-part1-01.txt) progresses to Draft Standard. Russ stated that Jim Schaad has developed an interoperability matrix for RFCs 2630 through 2634. Once completed, the matrix will indicate which features have and have not been implemented. So far, Microsoft and J.G. Van Dyke and Associates (VDA) have provided input to the interoperability matrix. Russ asked that other organizations that have developed S/MIME v3 capabilities should contribute to the matrix. Russ stated that testing of the example data included in the "Examples of S/MIME Messages" I-D is providing informal inputs for the matrix. Paul Hoffman stated that that other code bases also need to be tested. He welcomed feedback from novice developers. He has offered to coordinate interoperability testing. In the past, Paul has coordinated face-to-face SecureConnect interoperability events. He believes that future interoperability testing will not be face-to-face, but will be supported via a bulletin board or e-mail. He will announce any S/MIME inter events on the S/MIME WG mail list. Those events will be discussed in detail on the S/MIME developers mail list +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Mapping Company Classification Policy to the S/MIME Security Label - Russ Housley The "Implementing Company Classification Policy with the S/MIME Security Label" I-D, , December 1999, was authored by Weston Nicolls. It is planned that the document will become an Informational RFC. It describes how the ESS Security Label can be used to implement an organizational security policy. It includes three organizational examples: Whirlpool, Caterpillar and Amoco. One use of this document is to provide sample policies for interoperability testing. The document includes the security policy for Amoco Corporation as follows: - Confidentiality: General, Confidential, Highly Confidential - Integrity: Minimum, Medium, Maximum It includes the security policy for Caterpillar Inc as follows: - Confidentiality: Public, Confidential Green, Confidential Yellow, Confidential Red It includes the security policy for Whirlpool Corporation as follows: - Confidentiality: Public, Internal, Confidential - Additional marks at discretion of owner: - Privacy Marks? - Security Categories? - Do they require access control? Way Forward: - Support interoperability testing - Need to assign Object Identifiers: IETF values for this document and testing - Organizations assign their own After discussion with Weston Nicolls, who could not be present at this meeting, three object identifiers were assigned to permit the Whirlpool, Caterpillar and Amoco security policies to be used in interoperability testing. These object identifiers are not the ones that will be used by the companies, rather they are intended for testing. The object identifiers are: -- S/MIME Working Group Object Identifier Registry id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } -- Test Security Policies Arc id-tsp OBJECT IDENTIFIER ::= { id-smime 7 } -- Test Security Policies id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 } id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 } id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 } +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CERTDIST Draft Discussion - Jim Schaad Jim discussed the Certificate Distribution Specification I-D , October 20, 1999. The CERTDIST I-D was submitted for S/MIME WG "last call" for comments on 22 October 1999. Jim stated that he received comments regarding the following topics: - LDAP Directory Attribute layout - Additional arguments against CERTDIST Section 2 (current methods of publishing certificates) - miscellaneous minor comments Jims stated that he plans to publish an updated version of the CERTDIST I-D soon. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Symmetric Key Distribution - Sean Turner Sean discussed the S/MIME Symmetric Key Distribution I-D, , December 20, 1999. He stated that the design goals are to provide a transport independent mechanism for distribution of symmetric keys to a group of users. The mechanism must use RFC 2630. It must maximize the reuse of existing group/list management techniques (listserv, majordomo, etc). Seam explained the diagrams included in the I-D. Sean stated that he did not know of any patents regarding the secure distribution of symmetric keys. He asked if anybody else knew of any patents. Nobody replied. Paul Hoffman pointed out that the majordomo mail list server software does not support all mail list features. He stated that the SYMPA mail list server includes a database and rich set of features. Paul also pointed out that customers ask him on a monthly basis for secure mail list capabilities, so he knows that there are real requirements for these capabilities. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DOMSEC Draft Discussion - Bill Ottaway Bill presented a briefing regarding the "Domain Security Services Using S/MIME" I-D . He stated that there are minor differences between the -03 and -04 drafts as follows: - DOMSEC signatures are now added by encapsulation only. (Used to allow parallel signatures). - Allows order of third party signature application to be known. - More secure. - Section four re-written to aid understanding Bill discussed the proposed solution to an issue raised during the December 1999 S/MIME WG meeting. From those minutes: "Jim Schaad recommended that the domain name should be exactly matched. Jim also pointed out that RFC 2630 states that the content type should be id-data when there are no signers of a signedData object." Bill proposes that the original domain naming conventions should be preserved. Bill briefed that the users "must always rely on the CA to police naming conventions." Bill addressed Jim's other comment by adding text to the case when no originator signature is present to state that the eContentType will be id-data as specified in CMS. However, the eContent will contain the unsigned message instead of being left empty as suggested in CMS (section 2). This allows the DOMSEC signature to cover the message which does not have an originator signature. Bill stated that an object identifier must be obtained for the id-signatureType attribute. He believes that the document is ready for working group last call. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Interoperability Matrix - Jim Schaad Jim developed an interoperability matrix for RFCs 2630 through 2634. Jim has documented the features supported by Microsoft. VDA provided input to Jim regarding the capabilities of the S/MIME Freeware Library (SFL). VDA also provided input regarding interoperability testing conducted between the SFL and Microsoft. Jim asked for others to submit input to him at jimsch@nwlink.com. Jim also pointed out that there are some minor comments/questions to the RFCs that accompany the matrix. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Examples of S/MIME Messages - Paul Hoffman Paul stated that the "Examples of S/MIME Messages" I-D needs more input. He stated that VDA had tested the samples in the document and was planning to provide further sample data for inclusion in the document. He stated that the document is valuable because it includes the ASN.1 encoded examples. He stated that there is sample data that can be extracted using a Perl script that is also included in the document. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME WG Cryptographic Algorithm Specification - Russ Housley Russ briefed that the current S/MIME WG charter states: "The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of "mandatory to implement" algorithms may be selected." Russ briefed that the following I-Ds document the use of crypto algorithms with RFC 2630: 1) Use of the CAST-128 Encryption Algorithm in CMS, 2) CMS KEA and SKIPJACK Conventions, 3) CMS RSAES-OAEP Conventions, 4) Elliptic Curve S/MIME, 5) Incorporation of IDEA Encryption Algorithm in S/MIME Russ said that the following question was raised on the S/MIME WG mail list: "Should the specifications be published as Standards Track RFCs or Informational RFCs?" Russ stated that "mandatory-to- implement" algorithms will be published as Standards Track RFCs. He pointed out that the current S/MIME WG charter also states that complete algorithm specifications will be published as Standards Track RFCs. Jeff Schiller stated that he believes that all drafts describing the details of a crypto algorithm must be Informational because the IETF cannot control the definition of the crypto algorithms. Jeff further stated that he believes that all documents describing how crypto algorithms can be used with an IETF protocol can be Standards Track because the IETF can control the use of the crypto algorithms. He further stated that all documents describing how secret or proprietary crypto algorithms can be used can not be Standards Track. Russ applied Jeff's recommendations to the aforementioned list of I-Ds: 1) The "Use of the CAST-128 Encryption Algorithm in CMS" I-D can be a Standards Track document because the CAST 128 algorithm description is freely available. 2) The "CMS KEA and SKIPJACK Conventions" I-D can not be a Standards Track document because the U.S. Government has not freely published the description of the FORTEZZA 80-bit wrap function used to wrap the 80-bit SKIPJACK content encryption key. 3) The "CMS RSAES-OAEP Conventions" I-D can be a Standards Track document because the PKCS #1 v2.0 algorithm description is freely available. 4) The "Elliptic Curve S/MIME" I-D can be a Standards Track document because the algorithms are documented in ANSI X9.62 and ANSI X9.63. Paul Hoffman said that someone told him that Certicom has patents or pending patents on all of the "interesting and useful" curves. Russ agreed that Standards Track could only be achieved if the appropriate patent statements were made by Certicom or any other patent holder. 5) The "Incorporation of IDEA Encryption Algorithm in S/MIME" I-D can not be a Standards Track document because the IDEA crypto algorithm description is not freely available. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Application of Attribute Certificates (AC) in S/MIME - Greg Colla Greg's briefing addressed the topic of checking the e-mail address of the signedData signer against the e-mail address in the signer's certificate. Greg briefed that there are problems with binding the subject's e-mail address with the subject's public key in an X.509 public key certificate such as: - Multiple e-mail addresses - Maintenance of e-mail addresses - Security Proxy (a proxy signs and decrypts on behalf of many users) - Privacy/Spam Greg briefed the following requirements: Address Aliasing: Associate a single entity with multiple e-mail addresses, with a single PKC. Secure Proxying: Associate multiple entities, each with their own e-mail address, with a common PKC. Address Sharing: Associate multiple entities, each with their own PKC, with a single e-mail address. Greg proposed the following: - Maintenance of e-mail addresses limits S/MIME usability - ACs can be used to cryptographically bind e-mail addresses with PK certificates - E-mail ACs provide a flexible solution for maintaining e-mail addresses - Supplements current infrastructure - Localized modifications required to S/MIME components to use E-mail ACs - E-mail ACs can be used to solve other S/MIME limitations Greg summarized by stating that his proposal provides a strategy for removing email addresses from PK certificates. Greg's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding his proposal. Paul Hoffman stated that there are not many deployed ACs and that most companies have not implemented ACs. Paul stated his concern that the AC proposal will add confusion to and delay the deployment of S/MIME v3. He stated that ACs can be used in the future to solve problems. Greg Colla rebutted that they face these problems today (i.e. associated with binding e-mail addresses with public keys). Jim Schaad stated the following comments/questions regarding Greg's proposal: 1) Two directory lookups will be required for each recipient of an encrypted message. This added time delay will decrease overall performance. 2) How does this help keep email addresses private? People will mail ACs in messages. A "spam harvester" could obtain the e-mail addresses out of messages in transit or out of the directory. 3) Solves internal/external problem. 4) Favors this approach for gateway address identification. 5) Agrees with Paul Hoffman's comments regarding adding confusion. An attendee stated that CAs issue certificates and ISPs issue addresses. He asked whether Greg's proposal assumes that these two entities work closely together. Greg answered that an ISP could use an RA to create certificates. A system administrator could generate the AC. He made the point that the public key certificate generation is much more important. Another attendee stated that he doesn't agree that including e-mail addresses in certs is a problem. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Freeware Library (SFL) - John Pawling John provided an update briefing regarding the SFL which is a freeware implementation of RFC 2630 and RFC 2634. The SFL can be used with the Crypto++ freeware library to implement RFC 2631. The SFL provides functions to support use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL. John briefed that on 14 January 2000, the U.S. Department of Commerce published revisions to the Export Administration Regulations that changed the U.S. Government's encryption export policy. In accordance with these revised regulations, the unencumbered SFL source code is now freely available to everyone at: http://www.armadillo.huntsville.al.us/software/smime. Organizations can use the SFL as part of their applications without paying any royalties or licensing fees. There is a public license associated the SFL. The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA is developing the capability for the SFL to use any security library that provides a PKCS #11 interface. John stated that VDA had used the SFL to perform a significant amount of S/MIME v3 interop testing. VDA tested the majority of features in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs 2632 and 2633. VDA used the SFL to successfully process and produce the majority of features documented in "Examples of S/MIME Messages". A summary of the test results was sent to the S/MIME WG examples mail list . Complete test drivers and test data is available with the SFL. S/MIME v3 interoperability testing between the SFL and Microsoft successfully tested almost all signedData and envelopedData features using mandatory, RSA and Fortezza algorithm suites. For example, the SFL (using Crypto++) exchanged E-S D-H-protected envelopedData with Microsoft. Almost all of the ESS features were tested. For example, successful signed receipt interoperability testing was performed between the SFL and Microsoft. VDA verified that the SFL can produce and process the majority of the features documented in Jim Schaad's S/MIME v3 interoperability matrix. John sent the matrix to which VDA added the SFL test results to Jim Schaad for incorporation into the master S/MIME WG matrix. VDA developed sample objects that illustrate each feature in the matrix that the SFL supports. Complete test drivers and test data are available with the SFL. SFL interoperability testing is automated through use of test drivers and configuration files so it can be easily repeated and modified by VDA or independently by a third party. A third party could enhance the test drivers or incorporate them in an application such as an S/MIME interoperability testing auto-responder which organizations could use to test their S/MIME implementations. John also provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 version 3 certification path verification as specified in the 1997 X.509 Recommendation (except Delta CRLs are not implemented). The CML: validates X.509 certification paths and CRLs; provides local certificate/CRL storage functions; and provides remote directory retrieval via LDAP. The CML uses the Certificate Path Development Library (CPDL) developed by Cygnacom Solutions to robustly build certification paths including cross certificates. The CML complies with the majority of the RFC 2459 requirements. Organizations can use the CML as part of their applications without paying any royalties or licensing fees (see CML Public License). All CML source code is provided. CML is available at: http://www.armadillo.huntsville.al.us/software. John also discussed the VDA-enhanced SNACC Abstract Syntax Notation One (ASN.1) library that implements the Distinguished Encoding Rules (DER). John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the SFL and CML. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ETSI Electronic Signature Formats - John Ross John briefed regarding electronic signature formats for long term electronic signatures as part of the ETSI Electronic Signature Infrastructure Standardisation. John briefed that Special Task Force (STF) 155 includes: Task 1: Policies for Certificate Service Providers (CSP). Policy Requirements on CSP issuing Qualified Certificates Task 2: Electronic Signature Formats ETSI ES 201 733 & this Informational RFC Task 3: Profile for Qualified Certificates Task 4: Profile for TimeStamping Services John discussed the "Electronic Signature Formats for long term electronic signature" I-D, . John briefed that this document is proposed as an Informational RFC. It defines the format of an electronic signature that can remain valid over long periods. It includes features which can provide evidence as to its validity even if the signer later attempts to deny (repudiate) the validity of the signature. John stated that the contents of this Informational RFC will be technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C). He noted that the authors do not provide the IETF with any rights other than to publish as an Internet-Draft. John briefed that this document builds on other IETF standards such as RFC 2630 and RFC 2459. It will also build on coming standards such as the PKIX Timestamping protocol and PKIX AC profile. John discussed the proposal to split the draft document into two RFCs: one RFC dealing only with ES formats, the other one dealing only with a Signature Policy format. In such a case, the basis of this split will be, sections 6 and annex C will be removed from this document and placed in another RFC dealing with Signature policies. Also, the signature policy ASN.1 will be removed the current ASN.1 modules in annex A and placed in a new ASN.1 module in the other RFC dealing with Signature Policies. A separate OID for the Signature Policy arc would ease separation. Denis Pinkas made the point that the SigningCertificate signed attribute provides information about the signer and indicates the signer's AC that indicates which role the signer used to sign the data. The point was made that the Signature policy Identifier attribute is used by the signer to indicate the signature policy under which he is signing. The Signature policy Identifier attribute will contain a hash of the signature policy. The esformats-00 I-D provides further details regarding the definition and use of signature policies. John made the point that the esformats-00 I-D must be equivalent ETSI ES 201 733 V.1.1.1, so major changes can't be made to the esformats-00 I-D. Sean Turner asked how the ETSI Electronic Signature format relates to the timestamping work being done in the PKIX WG. Denis Pinkas answered that the ETSI Electronic Signature work uses CMS and will build on the PKIX Timestamping protocol. Mike Myers asked if the PKIX Data Validation and Certification Server (DVCS) Protocols would satisfy the ETSI Electronic Signature requirements. Peter Sylvester said that the DVCS protocol could include the ETSI Electronic Signature information. Denis stated the protocols could be used together, but don't have to be. Sean Turner asked if the S/MIME WG cared about the contents of the esformats-00 I-D, since they can't change it anyway. John Ross replied that the signature policy portion of the I-D can be changed, but that the Electronic Signature format can not be changed. John welcomed input to the signature policy portion of the I-D. Russ Housley asked if the signature policy portion of the I-D was covered under the ETSI copyright. John Ross said that it was. He further stated that they are working on getting the copyright rules relaxed regarding this topic. ETSI may split the ES 201 733 V.1.1.1 document into two parts to be consistent with a split in the esformats-00 I-D. A straw poll of the attendees favored splitting the esformats-00 I-D. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Wrap Up - Russ Housley Russ stated that the "Use of the CAST-128 Encryption Algorithm in CMS" I-D was in working group last call. Jim Schaad stated that he had provided comments to the document. Russ stated that a new draft of the I-D will be submitted for IETF-wide last call. Russ stated that he would like to issue last call for the "Password-based Encryption for S/MIME" I-D. Jim Schaad stated that he had provided significant comments to the document. John Pawling pointed out that several people had questioned why the I-D defined yet another key wrapping algorithm. Russ said that Peter Gutmann needs to address these comments on the mail list. Russ pointed out that the process of transforming a password to a key would be documented in a separate RFC. Russ discussed the "Compressed Data Content Type for S/MIME" I-D. Peter Gutmann sent a message to the S/MIME WG mail list asking: "Does anyone have any further thoughts on compression as a CMS content type vs a MIME type?" Russ said that the S/MIME WG needed to make a decision regarding Peter's question. Paul Hoffman stated that compression has been discussed on the MIME mail list, but it has not been standardized. He said that the issue needs to get resolved. Russ stated that Jeff Schiller recommended that the S/MIME WG "just do it" because the issue needs to be resolved for efficiency purposes. Russ took a straw poll and only three people expressed an opinion. Meeting adjourned. From owner-ietf-smime Tue May 9 03:30:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14101 for ietf-smime-bks; Tue, 9 May 2000 03:30:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14097 for ; Tue, 9 May 2000 03:30:48 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13950; Tue, 9 May 2000 06:36:41 -0400 (EDT) Message-Id: <200005091036.GAA13950@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cmskea-05.txt Date: Tue, 09 May 2000 06:36:40 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the KEA and SKIPJACK Algorithms in CMS Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-05.txt Pages : 10 Date : 08-May-00 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word 'subscribe' in the body of the message. There is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cmskea-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmskea-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cmskea-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000508111932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmskea-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmskea-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000508111932.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue May 9 06:05:48 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA18213 for ietf-smime-bks; Tue, 9 May 2000 06:05:48 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18209 for ; Tue, 9 May 2000 06:05:47 -0700 (PDT) Received: by sentry.gw.tislabs.com; id JAA10358; Tue, 9 May 2000 09:13:30 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010342; Tue, 9 May 00 09:12:55 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA17816 for ietf-smime@imc.org; Tue, 9 May 2000 09:06:12 -0400 (EDT) Date: Tue, 9 May 2000 09:06:12 -0400 (EDT) From: "David M. Balenson" Message-Id: <200005091306.JAA17816@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: C A L L F O R P A P E R S The Internet Society 2001 Network and Distributed System Security Symposium (NDSS'01) February 7-9, 2001 Catamaran Resort, San Diego, California IMPORTANT DATES Paper Submission due: August 2, 2000 Author Notification: September 27, 2000 Camera-ready final papers due: October 31, 2000 GOAL: This symposium will foster information exchange among researchers and practioners of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce: e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Public Key Infrastructure. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, database management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures. * Network Perimeter Controls: firewalls, packet filters, application gateways. * Virtual Private Networks. BEST PAPER AWARD: There will be a best paper award again this year. The award will be presented at the symposium to the authors of the best overall paper as selected by the Program Committee. SUBMISSIONS: The Program Committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may - at the discretion of the panel chair - include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by August 2, 2000, and must be made via electronically in either PostScript or ASCII format. If the Committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. Submission information can be found at http://www.isoc.org/ndss01/cfp. Dates, final call for papers, advance program, and registration information will be available soon at http://www.isoc.org/ndss01. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program Co-chairs as indicated below. Authors and panelists will be notified of acceptance by September 27, 2000. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 31, 2000. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society PROGRAM COMMITTEE: Bennet Yee, University of California San Diego Bill Cheswick, Bell Labs Dave Kormann, AT&T Labs - Research David Aucksmith, Intel Corportation David P. Maher, Intertrust David Wagner, UC Berkeley Edward W. Felten, Princeton University Fabian Monrose, Bell Labs Gary McGraw, Reliable Software Technologies James Ellis, Sun Microsystems Kevin McCurley, IBM Almaden Research Center Matt Bishop, UC Davis Mudge, L0pht Heavy Industries, Inc. Peter Gutmann, University of Auckland, New Zealand Radia Perlman, Sun Microsystems Sandra Murphy, Network Associates Tom Berson, Anagram Laboratories Virgil D. Gligor, University of Maryland From owner-ietf-smime Tue May 9 08:40:55 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA21143 for ietf-smime-bks; Tue, 9 May 2000 08:40:55 -0700 (PDT) Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21136 for ; Tue, 9 May 2000 08:40:51 -0700 (PDT) Message-Id: <200005091540.IAA21136@ns.secondary.com> Received: from MGM (DEMONA [192.117.162.76]) by hal9000.vguard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQR623MB; Tue, 9 May 2000 18:46:06 +0200 X-MG-RegisteredMail: ReturnReceipt From: Raviv Karnieli To: housley@spyrus.com Cc: ietf-smime@imc.org Subject: RE: S/MIME IDEA Draft Date: Tue, 09 MAY 2000 16:44:00 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="<<-- MailGuardian RTF boundary -->>" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --<<-- MailGuardian RTF boundary -->> Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: base64 UnVzcywNCg0KVGhlIG5vdGUgZnJlZXMgb25seSB0aGUgbm9uIGNvbW1lcmNpYWwgdXNlIG9m IHRoaXMgYWxnb3JpdGhtLiBJIGJlbGlldmUgbW9zdCBvZiB0aGUgaW1wbGVtZW50YXRpb25z IG9mIFMvTUlNRXYzIHdpbGwgYmUgY29tbWVyY2lhbCBwcm9kdWN0cyBvciBzeXN0ZW1zIGZv ciBjb21tZXJjaWFsIHVzZSBzbyB0aGlzIG5vdGUgZG9lcyBub3QgcmVsYXRlIHRvIHRoZW0u IElzIGl0IHNvPw0KDQpSYXZpdiBLYXJuaWVsaSAtIENUTw0KVmFuZ3VhcmQgU2VjdXJpdHkg VGVjaG5vbG9naWVzIEx0ZC4NClRlbC4gKzk3Mi00LTk4OS0xMzExICAgICAgIEZheCArOTcy LTQtOTg5LTEzMjINCnd3dy52Z3VhcmQuY29tICAgICAgICAgICAgIHJhdml2QHZndWFyZC5j b20NCg0KVGhpcyBtZXNzYWdlIGxlZnQgbXkgY29tcHV0ZXIgc2VjdXJlZCBzaW5jZSBJkm0g dXNpbmcgDQpNQUlMZ3VhcmRpYW4gRW50ZXJwcmlzZSB0aGUgZmlyc3QgdHJ1ZSBlbmQgdG8g ZW5kIGVudGVycHJpc2UgZS1tYWlsIHNlY3VyaXR5IHNvbHV0aW9uIHRoYXQgaXMgcG9saWN5 IGJhc2VkLCBjZW50cmFsbHkgbWFuYWdlZCBhbmQgdG90YWxseSB0cmFuc3BhcmVudCB0byB0 aGUgZW5kIHVzZXJzLg0KDQpZb3UgY2FuIGdldCB5b3VyIG93biBmcmVlIGV2YWx1YXRpb24g Y29weSBvZiBNQUlMZ3VhcmRpYW4gDQphdCBodHRwOi8vd3d3LnZndWFyZC5jb20vcHJvZC5h c3ANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSdXNzIEhvdXNsZXkgW21h aWx0bzpob3VzbGV5QHNweXJ1cy5jb21dDQpTZW50OiBNb25kYXksIE1heSAwOCwgMjAwMCAz OjM3IFBNDQpUbzogaWV0Zi1zbWltZUBpbWMub3JnDQpTdWJqZWN0OiBTL01JTUUgSURFQSBE cmFmdA0KDQoNCkkgaGF2ZSBqdXN0IGJlZW4gbWFkZSBhd2FyZSB0aGF0IHRoZSBJREVBIGVu Y3J5cHRpb24gYWxnb3JpdGhtIGhhcyBiZWVuIA0KcG9zdGVkIG9uIHRoZSAiSUVURiBQYWdl IG9mIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgTm90aWNlcyIgd2ViIHNpdGU6DQoJ aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmL0lQUi9BU0NPTS1JREVBDQoNCkFsc28sIFN0ZXBo YW4gdGVsbHMgbWUgdGhhdCBhIG5ldyBJbnRlcm5ldC1EcmFmdCB3aWxsIGJlIHBvc3RlZCBp biB0aGUgbmV4dCANCmZldyBkYXlzLiAgT25jZSBpdCBpcyBwb3N0ZWQsIEkgd2lsbCBiZSBj YWxsaW5nIGZvciBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCANCm9uIHRoaXMgZG9jdW1lbnQu DQoNCkJ5IHRoZSB3YXksIEkgaGF2ZSBhc2tlZCB0aGUgYXV0aG9ycyB0byBjaGFuZ2UgdGhl IHRpdGxlLiAgVGhlIG5ldyB0aXRsZSANCndpbGwgYmU6DQoJVXNlIG9mIHRoZSBJREVBIEVu Y3J5cHRpb24gQWxnb3JpdGhtIGluIENNUw0KDQpSdXNz --<<-- MailGuardian RTF boundary -->> Content-Type: application/X-MAILguardian-rtf; charset="ISO-8859-8" Content-Transfer-Encoding: base64 DQp7XHJ0ZjFcYW5zaVxhbnNpY3Bn MTI1Mlxmcm9tdGV4dCBcZGVmZjB7XGZvbnR0YmwNCntcZjBcZnN3aXNzXGZjaGFyc2V0MCBB cmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0 MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMx XHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIFJ1c3MsXHBhcg0KXHBhcg0KVGhlIG5v dGUgZnJlZXMgb25seSB0aGUgbm9uIGNvbW1lcmNpYWwgdXNlIG9mIHRoaXMgYWxnb3JpdGht LiBJIGJlbGlldmUgbW9zdCBvZiB0aGUgaW1wbGVtZW50YXRpb25zIG9mIFMvTUlNRXYzIHdp bGwgYmUgY29tbWVyY2lhbCBwcm9kdWN0cyBvciBzeXN0ZW1zIGZvciBjb21tZXJjaWFsIHVz ZSBzbyB0aGlzIG5vdGUgZG9lcyBub3QgcmVsYXRlIHRvIHRoZW0uIElzIGl0IHNvP1xwYXIN ClxwYXINClJhdml2IEthcm5pZWxpIC0gQ1RPXHBhcg0KVmFuZ3VhcmQgU2VjdXJpdHkgVGVj aG5vbG9naWVzIEx0ZC5ccGFyDQpUZWwuICs5NzItNC05ODktMTMxMSAgICAgICBGYXggKzk3 Mi00LTk4OS0xMzIyXHBhcg0Kd3d3LnZndWFyZC5jb20gICAgICAgICAgICAgcmF2aXZAdmd1 YXJkLmNvbVxwYXINClxwYXINClRoaXMgbWVzc2FnZSBsZWZ0IG15IGNvbXB1dGVyIHNlY3Vy ZWQgc2luY2UgSVwnOTJtIHVzaW5nIFxwYXINCk1BSUxndWFyZGlhbiBFbnRlcnByaXNlIHRo ZSBmaXJzdCB0cnVlIGVuZCB0byBlbmQgZW50ZXJwcmlzZSBlLW1haWwgc2VjdXJpdHkgc29s dXRpb24gdGhhdCBpcyBwb2xpY3kgYmFzZWQsIGNlbnRyYWxseSBtYW5hZ2VkIGFuZCB0b3Rh bGx5IHRyYW5zcGFyZW50IHRvIHRoZSBlbmQgdXNlcnMuXHBhcg0KXHBhcg0KWW91IGNhbiBn ZXQgeW91ciBvd24gZnJlZSBldmFsdWF0aW9uIGNvcHkgb2YgTUFJTGd1YXJkaWFuIFxwYXIN CmF0IGh0dHA6Ly93d3cudmd1YXJkLmNvbS9wcm9kLmFzcFxwYXINCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tXHBhcg0KRnJvbTogUnVzcyBIb3VzbGV5IFttYWlsdG86aG91c2xleUBz cHlydXMuY29tXVxwYXINClNlbnQ6IE1vbmRheSwgTWF5IDA4LCAyMDAwIDM6MzcgUE1ccGFy DQpUbzogaWV0Zi1zbWltZUBpbWMub3JnXHBhcg0KU3ViamVjdDogUy9NSU1FIElERUEgRHJh ZnRccGFyDQpccGFyDQpccGFyDQpJIGhhdmUganVzdCBiZWVuIG1hZGUgYXdhcmUgdGhhdCB0 aGUgSURFQSBlbmNyeXB0aW9uIGFsZ29yaXRobSBoYXMgYmVlbiBccGFyDQpwb3N0ZWQgb24g dGhlICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBOb3RpY2Vz IiB3ZWIgc2l0ZTpccGFyDQpcdGFiIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi9JUFIvQVND T00tSURFQVxwYXINClxwYXINCkFsc28sIFN0ZXBoYW4gdGVsbHMgbWUgdGhhdCBhIG5ldyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGJlIHBvc3RlZCBpbiB0aGUgbmV4dCBccGFyDQpmZXcgZGF5 cy4gIE9uY2UgaXQgaXMgcG9zdGVkLCBJIHdpbGwgYmUgY2FsbGluZyBmb3IgV29ya2luZyBH cm91cCBMYXN0IENhbGwgXHBhcg0Kb24gdGhpcyBkb2N1bWVudC5ccGFyDQpccGFyDQpCeSB0 aGUgd2F5LCBJIGhhdmUgYXNrZWQgdGhlIGF1dGhvcnMgdG8gY2hhbmdlIHRoZSB0aXRsZS4g IFRoZSBuZXcgdGl0bGUgXHBhcg0Kd2lsbCBiZTpccGFyDQpcdGFiIFVzZSBvZiB0aGUgSURF QSBFbmNyeXB0aW9uIEFsZ29yaXRobSBpbiBDTVNccGFyDQpccGFyDQpSdXNzXHBhcg0KfQ0K --<<-- MailGuardian RTF boundary -->>-- From owner-ietf-smime Tue May 9 10:41:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23618 for ietf-smime-bks; Tue, 9 May 2000 10:41:42 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23520; Tue, 9 May 2000 10:39:22 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies From owner-ietf-smime Thu May 11 02:41:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06349 for ietf-smime-bks; Thu, 11 May 2000 02:41:38 -0700 (PDT) Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06343 for ; Thu, 11 May 2000 02:41:36 -0700 (PDT) Date: 11 May 2000 11:44:37 +0200 From: Laurent Deffranne To: ietf-smime Subject: Does Smime works fine with Windows 2000 PKI Message-Id: <0D29A391A8105001*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi everybody, Just a question : Is there any known issues using S/MIME with Win2000PKI-certificates ? More generally, are Win2000 certificates usable with (and understood by ) the others mailers (especially Lotus Notes, Netscape, Eudora +plug-in?) Isn't Baltimore Unicert a "better choice" due to its greater compatibility ? Any advices are welcome. Regards, Laurent Deffranne From owner-ietf-smime Thu May 11 05:47:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA15143 for ietf-smime-bks; Thu, 11 May 2000 05:47:57 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15139 for ; Thu, 11 May 2000 05:47:52 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id IAA12142; Thu, 11 May 2000 08:54:05 -0400 (EDT) From: "Walter Williams" To: "Laurent Deffranne" , "ietf-smime" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 08:44:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01BFBB25.20A8F130" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <0D29A391A8105001*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BFBB25.20A8F130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Laurent; Yes, certs issued from a W2K CA can be used for S/MIME, and no less so than certs issued from Baltimore, Iplanet or any other CA vendor or product. The main issue is not will they work, but will you be able to validate the certs. Unless the person issuing the cert from W2K has provided you with their server's cert, or they have certified their CA with the signature of the publicly known CAs you will not be able to easily verify the signature to its source. This is not the most technically acurate way of saying this but I'm not awake yet. Baltimore has preregistered there CA with the vendors distributing products, as has Verisign, Thaught, and many others. Just make certain that you have the certificates for the W2K CA, and access to its revocation list so you can validate properly and you'll be fine. Walt Williams TSD-Systems Senior IT Analyst Genuity www.genuity.com Please note: GTE Internetworking is now Genuity. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > Sent: Thursday, May 11, 2000 5:45 AM > To: ietf-smime > Subject: Does Smime works fine with Windows 2000 PKI > > > Hi everybody, > > Just a question : > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > More generally, are Win2000 certificates usable with (and > understood by ) the others mailers (especially Lotus Notes, > Netscape, Eudora +plug-in?) > > Isn't Baltimore Unicert a "better choice" due to its greater > compatibility ? > > Any advices are welcome. > > Regards, > > Laurent Deffranne ------=_NextPart_000_0000_01BFBB25.20A8F130 Content-Type: text/x-vcard; name="Walter B Williams.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Walter B Williams.vcf" BEGIN:VCARD VERSION:2.1 N:Williams;Walter;B;Mr. FN:Walter B Williams NICKNAME:Walt ORG:Genuity Inc.;TSD TITLE:Senior IT Analyst TEL;WORK;VOICE:617-873-5888 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;2/221B;50 Moulton St=3D0D=3D0AMS = 2/2A;Cambridge;MA;02138;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:2/221B=3D0D=3D0A50 Moulton = St=3D0D=3D0AMS 2/2A=3D0D=3D0ACambridge, MA 02138=3D0D=3D0AUSA URL: URL:http://www.genuity.com EMAIL;PREF;INTERNET:walter.williams@genuity.com REV:20000407T003737Z END:VCARD ------=_NextPart_000_0000_01BFBB25.20A8F130-- From owner-ietf-smime Thu May 11 06:15:59 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA15752 for ietf-smime-bks; Thu, 11 May 2000 06:15:59 -0700 (PDT) Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15748 for ; Thu, 11 May 2000 06:15:57 -0700 (PDT) Date: 11 May 2000 15:19:05 +0200 From: Laurent Deffranne To: "walter.williams" cc: ietf-smime Subject: RE: Does Smime works fine with Windows 2000 PKI Message-Id: <13F9A391AB349012*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PART.BOUNDARY.spdl113.58e8.391ab34c.0001" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --PART.BOUNDARY.spdl113.58e8.391ab34c.0001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: Quoted-Printable Content-Disposition: inline Walt, Do you mean that there are difficulties to access through LDAP an Active Di= rectory, as you want to read or use X509 certificates ? By the way,does somebody know issues about Active Directory LDAP, or issues= to read a certificate in an Active Directory ? For me it would be a mistake to use now the "brand new" Active Directory, b= ut if someone could tell me where I can find proofs of lack of compatibilit= y (from Microsoft, there must be surely one of two), this would interrest m= e.=20 Laurent walter.williams%genuity.com@Internet 11/05/2000 14:54 To:=09Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet cc:=09=20 Subject:=09RE: Does Smime works fine with Windows 2000 PKI Laurent; Yes, certs issued from a W2K CA can be used for S/MIME, and no less so than= certs issued from Baltimore, Iplanet or any other CA vendor or product. Th= e main issue is not will they work, but will you be able to validate the certs. Unless the person issuing the cert from W2K has provided you with their server's cert, or they have certified their CA with the signature of the publicly known CAs you will not be able to easily verify the signature to its source. This is not the most technically acurate way of saying this= but I'm not awake yet. Baltimore has preregistered there CA with the vendors distributing products, as has Verisign, Thaught, and many others. Just make certain that you have the certificates for the W2K CA, and access= to its revocation list so you can validate properly and you'll be fine. Walt Williams TSD-Systems Senior IT Analyst Genuity www.genuity.com Please note: GTE Internetworking is now Genuity. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > Sent: Thursday, May 11, 2000 5:45 AM > To: ietf-smime > Subject: Does Smime works fine with Windows 2000 PKI > > > Hi everybody, > > Just a question : > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > More generally, are Win2000 certificates usable with (and > understood by ) the others mailers (especially Lotus Notes, > Netscape, Eudora +plug-in?) > > Isn't Baltimore Unicert a "better choice" due to its greater > compatibility ? > > Any advices are welcome. > > Regards, > > Laurent Deffranne --PART.BOUNDARY.spdl113.58e8.391ab34c.0001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Walter B Williams.vcf" Content-Description: Walter B Williams.vcf FTBP-Modification-Date: 11 May 2000 15:19:00 +0200 FTBP-Object-Size: 470 BEGIN:VCARD VERSION:2.1 N:Williams;Walter;B;Mr. FN:Walter B Williams NICKNAME:Walt ORG:Genuity Inc.;TSD TITLE:Senior IT Analyst TEL;WORK;VOICE:617-873-5888 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;2/221B;50 Moulton St=0D=0AMS 2/2A;Cambridge;MA;02138;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2/221B=0D=0A50 Moulton St=0D=0AMS 2/2A=0D=0ACambridge, MA 02138=0D=0AUSA URL: URL:http://www.genuity.com EMAIL;PREF;INTERNET:walter.williams@genuity.com REV:20000407T003737Z END:VCARD --PART.BOUNDARY.spdl113.58e8.391ab34c.0001-- From owner-ietf-smime Thu May 11 06:30:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA15961 for ietf-smime-bks; Thu, 11 May 2000 06:30:04 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15957 for ; Thu, 11 May 2000 06:30:03 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id JAA25422; Thu, 11 May 2000 09:36:18 -0400 (EDT) From: "Walter Williams" To: "Laurent Deffranne" Cc: "ietf-smime" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 09:26:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <13F9A391AB349012*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let me take the points one at a time and inline: > -----Original Message----- > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > Sent: Thursday, May 11, 2000 9:19 AM > To: walter.williams > Cc: ietf-smime > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > Walt, > > Do you mean that there are difficulties to access through LDAP an > Active Directory, as you want to read or use X509 certificates ? > No. However, are you going to open your active directory to anonymous LDAP queries over the Internet? If not, are you limiting S/MIME to internal use only? If not then you are somewhat back to square one. > By the way,does somebody know issues about Active Directory LDAP, > or issues to read a certificate in an Active Directory ? This worked just fine for us here, but the problem we had with AD was that it does not support inetOrgPerson, and thus can't easily be synched up with most external LDAP directories. You'll find you'll want a metadirectory connector to synch it with any external directory. Again, this is not an issue if you're willing to directly expose AD to internet use. > > For me it would be a mistake to use now the "brand new" Active > Directory, but if someone could tell me where I can find proofs > of lack of compatibility (from Microsoft, there must be surely > one of two), this would interrest me. > AD seems to work just fine, if you don't mind working with something with a proprietary schema. Any LDAP and S/MIME aware client we pointed at it understood the contents just fine, so the schema does not seem to impact client interoperability. > Laurent > > > > > > walter.williams%genuity.com@Internet > 11/05/2000 14:54 > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > cc: > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > Laurent; > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > less so than > certs issued from Baltimore, Iplanet or any other CA vendor or > product. The > main issue is not will they work, but will you be able to validate the > certs. Unless the person issuing the cert from W2K has provided you with > their server's cert, or they have certified their CA with the signature of > the publicly known CAs you will not be able to easily verify the signature > to its source. This is not the most technically acurate way of > saying this > but I'm not awake yet. Baltimore has preregistered there CA with the > vendors distributing products, as has Verisign, Thaught, and many others. > Just make certain that you have the certificates for the W2K CA, > and access > to its revocation list so you can validate properly and you'll be fine. > > Walt Williams > TSD-Systems > Senior IT Analyst > Genuity > www.genuity.com > > Please note: GTE Internetworking is now Genuity. > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > Sent: Thursday, May 11, 2000 5:45 AM > > To: ietf-smime > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > Hi everybody, > > > > Just a question : > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > More generally, are Win2000 certificates usable with (and > > understood by ) the others mailers (especially Lotus Notes, > > Netscape, Eudora +plug-in?) > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > compatibility ? > > > > Any advices are welcome. > > > > Regards, > > > > Laurent Deffranne > > > > From owner-ietf-smime Thu May 11 06:44:34 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA16171 for ietf-smime-bks; Thu, 11 May 2000 06:44:34 -0700 (PDT) Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16167 for ; Thu, 11 May 2000 06:44:32 -0700 (PDT) Date: 11 May 2000 15:48:21 +0200 From: Laurent Deffranne To: "walter.williams" cc: ietf-smime Subject: RE: Does Smime works fine with Windows 2000 PKI Message-Id: <15306391ABA25043*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What would happen if you want to open the directory to anonymous access to the Web ? In such a way that you could exchange S/MIME certs with outside people ? walter.williams%genuity.com@Internet 11/05/2000 15:35 To: Laurent Deffranne/GKBCCB@GKBCCB cc: ietf-smime%imc.org@Internet Subject: RE: Does Smime works fine with Windows 2000 PKI Let me take the points one at a time and inline: > -----Original Message----- > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > Sent: Thursday, May 11, 2000 9:19 AM > To: walter.williams > Cc: ietf-smime > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > Walt, > > Do you mean that there are difficulties to access through LDAP an > Active Directory, as you want to read or use X509 certificates ? > No. However, are you going to open your active directory to anonymous LDAP queries over the Internet? If not, are you limiting S/MIME to internal use only? If not then you are somewhat back to square one. > By the way,does somebody know issues about Active Directory LDAP, > or issues to read a certificate in an Active Directory ? This worked just fine for us here, but the problem we had with AD was that it does not support inetOrgPerson, and thus can't easily be synched up with most external LDAP directories. You'll find you'll want a metadirectory connector to synch it with any external directory. Again, this is not an issue if you're willing to directly expose AD to internet use. > > For me it would be a mistake to use now the "brand new" Active > Directory, but if someone could tell me where I can find proofs > of lack of compatibility (from Microsoft, there must be surely > one of two), this would interrest me. > AD seems to work just fine, if you don't mind working with something with a proprietary schema. Any LDAP and S/MIME aware client we pointed at it understood the contents just fine, so the schema does not seem to impact client interoperability. > Laurent > > > > > > walter.williams%genuity.com@Internet > 11/05/2000 14:54 > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > cc: > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > Laurent; > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > less so than > certs issued from Baltimore, Iplanet or any other CA vendor or > product. The > main issue is not will they work, but will you be able to validate the > certs. Unless the person issuing the cert from W2K has provided you with > their server's cert, or they have certified their CA with the signature of > the publicly known CAs you will not be able to easily verify the signature > to its source. This is not the most technically acurate way of > saying this > but I'm not awake yet. Baltimore has preregistered there CA with the > vendors distributing products, as has Verisign, Thaught, and many others. > Just make certain that you have the certificates for the W2K CA, > and access > to its revocation list so you can validate properly and you'll be fine. > > Walt Williams > TSD-Systems > Senior IT Analyst > Genuity > www.genuity.com > > Please note: GTE Internetworking is now Genuity. > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > Sent: Thursday, May 11, 2000 5:45 AM > > To: ietf-smime > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > Hi everybody, > > > > Just a question : > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > More generally, are Win2000 certificates usable with (and > > understood by ) the others mailers (especially Lotus Notes, > > Netscape, Eudora +plug-in?) > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > compatibility ? > > > > Any advices are welcome. > > > > Regards, > > > > Laurent Deffranne > > > > From owner-ietf-smime Thu May 11 07:00:26 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16388 for ietf-smime-bks; Thu, 11 May 2000 07:00:26 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16384 for ; Thu, 11 May 2000 07:00:25 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id KAA06872; Thu, 11 May 2000 10:06:43 -0400 (EDT) From: "Walter Williams" To: "Laurent Deffranne" Cc: "ietf-smime" Subject: RE: Does Slime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 09:57:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <15306391ABA25043*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Active directory would expose a significant amount of information you might not want the external world to know, such as a complete listing of all your w2k computers and their roles in your network. You could use a LDAP proxy server to provide what you want to the internet and keep the data in active directory. Innosoft (Now purchased by IPlanet) makes such a product. There are probably others on the market. > -----Original Message----- > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > Sent: Thursday, May 11, 2000 9:48 AM > To: walter.williams > Cc: ietf-smime > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > What would happen if you want to open the directory to anonymous > access to the Web ? > In such a way that you could exchange S/MIME certs with outside people ? > > > > > > > walter.williams%genuity.com@Internet > 11/05/2000 15:35 > To: Laurent Deffranne/GKBCCB@GKBCCB > cc: ietf-smime%imc.org@Internet > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > Let me take the points one at a time and inline: > > > -----Original Message----- > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > Sent: Thursday, May 11, 2000 9:19 AM > > To: walter.williams > > Cc: ietf-smime > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Walt, > > > > Do you mean that there are difficulties to access through LDAP an > > Active Directory, as you want to read or use X509 certificates ? > > > > No. However, are you going to open your active directory to > anonymous LDAP > queries over the Internet? If not, are you limiting S/MIME to > internal use > only? If not then you are somewhat back to square one. > > > By the way,does somebody know issues about Active Directory LDAP, > > or issues to read a certificate in an Active Directory ? > > This worked just fine for us here, but the problem we had with AD was that > it does not support inetOrgPerson, and thus can't easily be > synched up with > most external LDAP directories. You'll find you'll want a metadirectory > connector to synch it with any external directory. Again, this is not an > issue if you're willing to directly expose AD to internet use. > > > > For me it would be a mistake to use now the "brand new" Active > > Directory, but if someone could tell me where I can find proofs > > of lack of compatibility (from Microsoft, there must be surely > > one of two), this would interrest me. > > > AD seems to work just fine, if you don't mind working with > something with a > proprietary schema. Any LDAP and S/MIME aware client we pointed at it > understood the contents just fine, so the schema does not seem to impact > client interoperability. > > > Laurent > > > > > > > > > > > > walter.williams%genuity.com@Internet > > 11/05/2000 14:54 > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > cc: > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > Laurent; > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > less so than > > certs issued from Baltimore, Iplanet or any other CA vendor or > > product. The > > main issue is not will they work, but will you be able to validate the > > certs. Unless the person issuing the cert from W2K has > provided you with > > their server's cert, or they have certified their CA with the > signature of > > the publicly known CAs you will not be able to easily verify > the signature > > to its source. This is not the most technically acurate way of > > saying this > > but I'm not awake yet. Baltimore has preregistered there CA with the > > vendors distributing products, as has Verisign, Thaught, and > many others. > > Just make certain that you have the certificates for the W2K CA, > > and access > > to its revocation list so you can validate properly and you'll be fine. > > > > Walt Williams > > TSD-Systems > > Senior IT Analyst > > Genuity > > www.genuity.com > > > > Please note: GTE Internetworking is now Genuity. > > > > > -----Original Message----- > > > From: owner-ietf-smime@mail.imc.org > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > > Sent: Thursday, May 11, 2000 5:45 AM > > > To: ietf-smime > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > Hi everybody, > > > > > > Just a question : > > > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > > More generally, are Win2000 certificates usable with (and > > > understood by ) the others mailers (especially Lotus Notes, > > > Netscape, Eudora +plug-in?) > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > compatibility ? > > > > > > Any advices are welcome. > > > > > > Regards, > > > > > > Laurent Deffranne > > > > > > > > > > > From owner-ietf-smime Thu May 11 07:30:57 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16764 for ietf-smime-bks; Thu, 11 May 2000 07:30:57 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16758 for ; Thu, 11 May 2000 07:30:56 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.1/8.10.1) with ESMTP id e4BEZgP23734; Thu, 11 May 2000 07:35:42 -0700 (PDT) Message-ID: <391AC53E.F55DDCED@software-munitions.com> Date: Thu, 11 May 2000 07:35:42 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Walter Williams CC: Laurent Deffranne , ietf-smime Subject: Re: Does Slime works fine with Windows 2000 PKI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Walter Williams wrote: > > Active directory would expose a significant amount of information you might > not want the external world to know, such as a complete listing of all your > w2k computers and their roles in your network. You could use a LDAP proxy > server to provide what you want to the internet and keep the data in active > directory. Innosoft (Now purchased by IPlanet) makes such a product. There > are probably others on the market. > Question: Would it also disclose the name of all of the employees and their roles, something many outside recruiters would love to know? > > -----Original Message----- > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > Sent: Thursday, May 11, 2000 9:48 AM > > To: walter.williams > > Cc: ietf-smime > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > What would happen if you want to open the directory to anonymous > > access to the Web ? > > In such a way that you could exchange S/MIME certs with outside people ? > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > 11/05/2000 15:35 > > To: Laurent Deffranne/GKBCCB@GKBCCB > > cc: ietf-smime%imc.org@Internet > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > Let me take the points one at a time and inline: > > > > > -----Original Message----- > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > Sent: Thursday, May 11, 2000 9:19 AM > > > To: walter.williams > > > Cc: ietf-smime > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > Walt, > > > > > > Do you mean that there are difficulties to access through LDAP an > > > Active Directory, as you want to read or use X509 certificates ? > > > > > > > No. However, are you going to open your active directory to > > anonymous LDAP > > queries over the Internet? If not, are you limiting S/MIME to > > internal use > > only? If not then you are somewhat back to square one. > > > > > By the way,does somebody know issues about Active Directory LDAP, > > > or issues to read a certificate in an Active Directory ? > > > > This worked just fine for us here, but the problem we had with AD was that > > it does not support inetOrgPerson, and thus can't easily be > > synched up with > > most external LDAP directories. You'll find you'll want a metadirectory > > connector to synch it with any external directory. Again, this is not an > > issue if you're willing to directly expose AD to internet use. > > > > > > For me it would be a mistake to use now the "brand new" Active > > > Directory, but if someone could tell me where I can find proofs > > > of lack of compatibility (from Microsoft, there must be surely > > > one of two), this would interrest me. > > > > > AD seems to work just fine, if you don't mind working with > > something with a > > proprietary schema. Any LDAP and S/MIME aware client we pointed at it > > understood the contents just fine, so the schema does not seem to impact > > client interoperability. > > > > > Laurent > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > 11/05/2000 14:54 > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > > cc: > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Laurent; > > > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > > less so than > > > certs issued from Baltimore, Iplanet or any other CA vendor or > > > product. The > > > main issue is not will they work, but will you be able to validate the > > > certs. Unless the person issuing the cert from W2K has > > provided you with > > > their server's cert, or they have certified their CA with the > > signature of > > > the publicly known CAs you will not be able to easily verify > > the signature > > > to its source. This is not the most technically acurate way of > > > saying this > > > but I'm not awake yet. Baltimore has preregistered there CA with the > > > vendors distributing products, as has Verisign, Thaught, and > > many others. > > > Just make certain that you have the certificates for the W2K CA, > > > and access > > > to its revocation list so you can validate properly and you'll be fine. > > > > > > Walt Williams > > > TSD-Systems > > > Senior IT Analyst > > > Genuity > > > www.genuity.com > > > > > > Please note: GTE Internetworking is now Genuity. > > > > > > > -----Original Message----- > > > > From: owner-ietf-smime@mail.imc.org > > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > > > Sent: Thursday, May 11, 2000 5:45 AM > > > > To: ietf-smime > > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > Hi everybody, > > > > > > > > Just a question : > > > > > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > > > More generally, are Win2000 certificates usable with (and > > > > understood by ) the others mailers (especially Lotus Notes, > > > > Netscape, Eudora +plug-in?) > > > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > > compatibility ? > > > > > > > > Any advices are welcome. > > > > > > > > Regards, > > > > > > > > Laurent Deffranne > > > > > > > > > > > > > > > > > > -- Dennis Glatting Copyright (c) 2000 Software Munitions From owner-ietf-smime Thu May 11 07:42:50 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16953 for ietf-smime-bks; Thu, 11 May 2000 07:42:50 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16949 for ; Thu, 11 May 2000 07:42:49 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id KAA22375; Thu, 11 May 2000 10:48:54 -0400 (EDT) From: "Walter Williams" To: "Dennis Glatting" Cc: "Laurent Deffranne" , "ietf-smime" Subject: RE: Does Slime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 10:39:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <391AC53E.F55DDCED@software-munitions.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Again, all this depends on content made available through the proxy. You can, of course require access to any directory to be over authenticated bind into the directory, but that requires maintaing a user id and pw for anyone external to your company who wants to use s/mime. This is one of the reasons for Directory sync, it allows business partners to share directory information. That is why standards compliance is an issue here, and again, active directory will require a metadirectory connector to many of the directories already deployed. Walt > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Thursday, May 11, 2000 10:36 AM > To: Walter Williams > Cc: Laurent Deffranne; ietf-smime > Subject: Re: Does Slime works fine with Windows 2000 PKI > > > Walter Williams wrote: > > > > Active directory would expose a significant amount of > information you might > > not want the external world to know, such as a complete listing > of all your > > w2k computers and their roles in your network. You could use a > LDAP proxy > > server to provide what you want to the internet and keep the > data in active > > directory. Innosoft (Now purchased by IPlanet) makes such a > product. There > > are probably others on the market. > > > > Question: > Would it also disclose the name of all of the > employees and their roles, something many > outside recruiters would love to know? > > > > > -----Original Message----- > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > Sent: Thursday, May 11, 2000 9:48 AM > > > To: walter.williams > > > Cc: ietf-smime > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > What would happen if you want to open the directory to anonymous > > > access to the Web ? > > > In such a way that you could exchange S/MIME certs with > outside people ? > > > > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > 11/05/2000 15:35 > > > To: Laurent Deffranne/GKBCCB@GKBCCB > > > cc: ietf-smime%imc.org@Internet > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Let me take the points one at a time and inline: > > > > > > > -----Original Message----- > > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > > Sent: Thursday, May 11, 2000 9:19 AM > > > > To: walter.williams > > > > Cc: ietf-smime > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > Walt, > > > > > > > > Do you mean that there are difficulties to access through LDAP an > > > > Active Directory, as you want to read or use X509 certificates ? > > > > > > > > > > No. However, are you going to open your active directory to > > > anonymous LDAP > > > queries over the Internet? If not, are you limiting S/MIME to > > > internal use > > > only? If not then you are somewhat back to square one. > > > > > > > By the way,does somebody know issues about Active Directory LDAP, > > > > or issues to read a certificate in an Active Directory ? > > > > > > This worked just fine for us here, but the problem we had > with AD was that > > > it does not support inetOrgPerson, and thus can't easily be > > > synched up with > > > most external LDAP directories. You'll find you'll want a > metadirectory > > > connector to synch it with any external directory. Again, > this is not an > > > issue if you're willing to directly expose AD to internet use. > > > > > > > > For me it would be a mistake to use now the "brand new" Active > > > > Directory, but if someone could tell me where I can find proofs > > > > of lack of compatibility (from Microsoft, there must be surely > > > > one of two), this would interrest me. > > > > > > > AD seems to work just fine, if you don't mind working with > > > something with a > > > proprietary schema. Any LDAP and S/MIME aware client we pointed at it > > > understood the contents just fine, so the schema does not > seem to impact > > > client interoperability. > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > > 11/05/2000 14:54 > > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > > > cc: > > > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > Laurent; > > > > > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > > > less so than > > > > certs issued from Baltimore, Iplanet or any other CA vendor or > > > > product. The > > > > main issue is not will they work, but will you be able to > validate the > > > > certs. Unless the person issuing the cert from W2K has > > > provided you with > > > > their server's cert, or they have certified their CA with the > > > signature of > > > > the publicly known CAs you will not be able to easily verify > > > the signature > > > > to its source. This is not the most technically acurate way of > > > > saying this > > > > but I'm not awake yet. Baltimore has preregistered there > CA with the > > > > vendors distributing products, as has Verisign, Thaught, and > > > many others. > > > > Just make certain that you have the certificates for the W2K CA, > > > > and access > > > > to its revocation list so you can validate properly and > you'll be fine. > > > > > > > > Walt Williams > > > > TSD-Systems > > > > Senior IT Analyst > > > > Genuity > > > > www.genuity.com > > > > > > > > Please note: GTE Internetworking is now Genuity. > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-smime@mail.imc.org > > > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of > Laurent Deffranne > > > > > Sent: Thursday, May 11, 2000 5:45 AM > > > > > To: ietf-smime > > > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > > > > Hi everybody, > > > > > > > > > > Just a question : > > > > > > > > > > Is there any known issues using S/MIME with > Win2000PKI-certificates ? > > > > > More generally, are Win2000 certificates usable with (and > > > > > understood by ) the others mailers (especially Lotus Notes, > > > > > Netscape, Eudora +plug-in?) > > > > > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > > > compatibility ? > > > > > > > > > > Any advices are welcome. > > > > > > > > > > Regards, > > > > > > > > > > Laurent Deffranne > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Dennis Glatting > Copyright (c) 2000 Software Munitions > From owner-ietf-smime Thu May 11 08:08:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17678 for ietf-smime-bks; Thu, 11 May 2000 08:08:30 -0700 (PDT) Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17673 for ; Thu, 11 May 2000 08:08:28 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA07924 for ; Thu, 11 May 2000 08:14:30 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 08:13:31 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EAD4@vhqpostal.verisign.com> From: Philip Hallam-Baker To: ietf-smime Subject: Border directories Date: Thu, 11 May 2000 08:13:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_000F_01BFBB3A.158A5DB0"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01BFBB3A.158A5DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Re the W2K discussion: There is a problem with S/MIME's interaction with LDAP in general that is certainly not unique to W2K. LDAP operates off a completely different namespace to that of SMTP / RFC822. Furthermore there is no single authoritative registrar for the X.500 namespace as there is for DNS (yes I know that there are groups who claim that role but as far as I know their authority is not generally observed). The application of LDAP as an enterprise infrastructure is not compatible with its use as an internet infrastructure. An enterprise directory has much more information than anyone is going to make available outside the company for the likes of headhunters and competitors. The use of border directories is one possible solution. The DNS SRV record provides a convenient means of locating a border directory. If however the border directory is only goiung to provide a certificate lookup service why use LDAP when one can use HTTP with vastly less overhead and pain? If one is not going to support indexing and search facilities for the certificate repository why make them available at all? I would quite like to see an SRV information service of the following form defined: Service Name _SMIME-HTTP Protocol function: For an RFC822 address of the form abc@xyz.com one or more digital certificates are returned that provide a binding between the name abc@xyz.com and one or more public keys. Protocol: 1) Obtain the SRV record _SMIME-HTTP.xyz.com This contains the IP address a.b.c.d and the port p 2) Perform a retrieval query on http://a.b.c.d:p/ ? The result of the query is the necessary S/MIME certificate (s) where = "mailto:abc@xyz.com" or Base64 ( SHA1 ( "mailto:abc@xyz.com")) (which TBD) where = "something to do with specifying an acceptable certificate root" "something to do with whether intermediate certs are required" "something to do with the acceptable certificate format - default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc" "something that we thought up in the bar late one night at the IETF" My personal prefferance would be fgor the SHA1 blinded query since it compresses the querry and emphasizes the fact that searching for names ain't going to be a supported feature but it does not really make the job of searching any harder in reality. Phill ------=_NextPart_000_000F_01BFBB3A.158A5DB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE1MTQzM1owIwYJKoZI hvcNAQkEMRYEFJ2PvJHLjMZfjl374PKiYf6+rN3tMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAMUWm6+gfgepc/CN1iKh6H4fQexvNKiCr8C6OTCd8ZJWKGq3nmf1iGFqw6bEd6M5y 1hhvxIgkDNQvzdJZjNxZixtOqQRUsQj9lkwa86M9pqtd3TV901JMVNJWcclGl4lI7UdryjDWIHF5 C2BCq/jDOZwlM/lVy/7sxg2A0/AGAucAAAAAAAA= ------=_NextPart_000_000F_01BFBB3A.158A5DB0-- From owner-ietf-smime Thu May 11 08:09:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17698 for ietf-smime-bks; Thu, 11 May 2000 08:09:14 -0700 (PDT) Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17693 for ; Thu, 11 May 2000 08:09:12 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA05357; Thu, 11 May 2000 08:12:01 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 08:12:51 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EAD3@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Walter Williams'" , Laurent Deffranne , ietf-smime Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 08:12:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_000A_01BFBB39.FDB94250"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BFBB39.FDB94250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Actually it is possible to issue certs with W2K that are recognized automatically by other mail recipients with the VeriSign Gateway CA product. In practice however this does not remove the obligation to employ the required authentication standards... In general however interroperability is not a market differentiator that should provide a major competative advantage. If only one vendor can claim to be interoperable something odd is happening. It is failure to interoperate that is a market disadvantage! IETF mailing lists are not a good place for discussing, plugging specific vendor products (although most folk feel free to correct erroneous statements about their product like I did). Phill ------=_NextPart_000_000A_01BFBB39.FDB94250 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE1MTM1M1owIwYJKoZI hvcNAQkEMRYEFOg6u4FNZA4o0f7e4DoZIS8czsH0MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAkCQOdwEGNZVmQXLfORUP7kAVGGvN5TryNfXqpv+fR55SThgha/ZN6BS3GagTM8hc rtiqMyO/YJVcNkASMQ66Fon2MQF4fkYOYhaU8Gr75QRW9v9etB84U/QK6rNG8BqyxPJliAZ52yD9 pX8QlhPBD8zwp1ZvXpB9h7jXTQ8iIc0AAAAAAAA= ------=_NextPart_000_000A_01BFBB39.FDB94250-- From owner-ietf-smime Thu May 11 08:11:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17745 for ietf-smime-bks; Thu, 11 May 2000 08:11:20 -0700 (PDT) Received: from brownie.maxware.nl ([212.67.163.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17737 for ; Thu, 11 May 2000 08:11:17 -0700 (PDT) X-Internal-ID: 39180590000001B4 Received: from taita (192.168.1.61) by brownie.maxware.nl (NPlex 2.0.108); 11 May 2000 17:13:30 +0200 Message-ID: <01a701bfbb5c$04dc6040$3d01a8c0@maxware.nl> From: "Frank W. Nolden" To: "Walter Williams" , "Laurent Deffranne" Cc: "ietf-smime" References: Subject: Re: Does Slime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 17:17:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for jumping into this discussion, which I find very interesting. There is a way of publishing certificates to the outside world without opening up the AD. I think Walter mentioned in already and that is replicating only the certificate information (with some minor additional information like emailaddress, distinguished name, surname, tc) to an (LDAP) directory that is connected to the internet. Replicating this information cannot be done using the standard X.500 DISP protocol since Microsoft does not support that, but you can use LDIF files and other more sophisticated tools like our MaXware Directory Sync Engine. You could put LDAP proxy servers (MaXware also has these available as Innosoft does) in front of that for security purposes and attribute mapping. A major advantage is that you do not permit anyone in real time either via a proxy or not to access information in the AD. An extra (LDAP) directory is an extra security barrier to your AD and it will only publish the information you want to be available on the web, without risking access to your AD and without configuring the Access Control in AD. Regards, Frank Nolden ----- Original Message ----- From: "Walter Williams" To: "Laurent Deffranne" Cc: "ietf-smime" Sent: Thursday, May 11, 2000 15:57 Subject: RE: Does Slime works fine with Windows 2000 PKI > Active directory would expose a significant amount of information you might > not want the external world to know, such as a complete listing of all your > w2k computers and their roles in your network. You could use a LDAP proxy > server to provide what you want to the internet and keep the data in active > directory. Innosoft (Now purchased by IPlanet) makes such a product. There > are probably others on the market. > > > -----Original Message----- > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > Sent: Thursday, May 11, 2000 9:48 AM > > To: walter.williams > > Cc: ietf-smime > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > What would happen if you want to open the directory to anonymous > > access to the Web ? > > In such a way that you could exchange S/MIME certs with outside people ? > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > 11/05/2000 15:35 > > To: Laurent Deffranne/GKBCCB@GKBCCB > > cc: ietf-smime%imc.org@Internet > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > Let me take the points one at a time and inline: > > > > > -----Original Message----- > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > Sent: Thursday, May 11, 2000 9:19 AM > > > To: walter.williams > > > Cc: ietf-smime > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > Walt, > > > > > > Do you mean that there are difficulties to access through LDAP an > > > Active Directory, as you want to read or use X509 certificates ? > > > > > > > No. However, are you going to open your active directory to > > anonymous LDAP > > queries over the Internet? If not, are you limiting S/MIME to > > internal use > > only? If not then you are somewhat back to square one. > > > > > By the way,does somebody know issues about Active Directory LDAP, > > > or issues to read a certificate in an Active Directory ? > > > > This worked just fine for us here, but the problem we had with AD was that > > it does not support inetOrgPerson, and thus can't easily be > > synched up with > > most external LDAP directories. You'll find you'll want a metadirectory > > connector to synch it with any external directory. Again, this is not an > > issue if you're willing to directly expose AD to internet use. > > > > > > For me it would be a mistake to use now the "brand new" Active > > > Directory, but if someone could tell me where I can find proofs > > > of lack of compatibility (from Microsoft, there must be surely > > > one of two), this would interrest me. > > > > > AD seems to work just fine, if you don't mind working with > > something with a > > proprietary schema. Any LDAP and S/MIME aware client we pointed at it > > understood the contents just fine, so the schema does not seem to impact > > client interoperability. > > > > > Laurent > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > 11/05/2000 14:54 > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > > cc: > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Laurent; > > > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > > less so than > > > certs issued from Baltimore, Iplanet or any other CA vendor or > > > product. The > > > main issue is not will they work, but will you be able to validate the > > > certs. Unless the person issuing the cert from W2K has > > provided you with > > > their server's cert, or they have certified their CA with the > > signature of > > > the publicly known CAs you will not be able to easily verify > > the signature > > > to its source. This is not the most technically acurate way of > > > saying this > > > but I'm not awake yet. Baltimore has preregistered there CA with the > > > vendors distributing products, as has Verisign, Thaught, and > > many others. > > > Just make certain that you have the certificates for the W2K CA, > > > and access > > > to its revocation list so you can validate properly and you'll be fine. > > > > > > Walt Williams > > > TSD-Systems > > > Senior IT Analyst > > > Genuity > > > www.genuity.com > > > > > > Please note: GTE Internetworking is now Genuity. > > > > > > > -----Original Message----- > > > > From: owner-ietf-smime@mail.imc.org > > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > > > Sent: Thursday, May 11, 2000 5:45 AM > > > > To: ietf-smime > > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > Hi everybody, > > > > > > > > Just a question : > > > > > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > > > More generally, are Win2000 certificates usable with (and > > > > understood by ) the others mailers (especially Lotus Notes, > > > > Netscape, Eudora +plug-in?) > > > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > > compatibility ? > > > > > > > > Any advices are welcome. > > > > > > > > Regards, > > > > > > > > Laurent Deffranne > > > > > > > > > > > > > > > > > > > > From owner-ietf-smime Thu May 11 09:13:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18905 for ietf-smime-bks; Thu, 11 May 2000 09:13:49 -0700 (PDT) Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [193.63.53.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18900 for ; Thu, 11 May 2000 09:13:43 -0700 (PDT) Received: from crusader (actually host crusader.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (Mailer); Thu, 11 May 2000 17:19:35 +0100 Reply-To: "Colin.Robbins" From: Colin Robbins To: "'Philip Hallam-Baker'" , "'ietf-smime'" Subject: RE: Border directories Date: Thu, 11 May 2000 17:19:32 +0100 Message-ID: <003f01bfbb64$b19997a0$ea353fc1@nexor.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EAD4@vhqpostal.verisign.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Phill, This looks like a potential approach if you consider certificate recovery only. However, there are several other reasons why Border Directories are required in a corporate infrastructure. E.g., Sharing directory information with business partners - you many want them to have access to email addresses, but not home telephone numbers. E.g., Providing different access to employees depending on whether they are currently inside or outside of your firewall. E.g., Allowing different access modes, for example preventing LDAP modify operations entering your network from untrusted sites. Colin And just to add our name to the list - NEXOR has an LDAP proxy product as well! > > The use of border directories is one possible solution. The DNS SRV > record provides a convenient means of locating a border directory. > > If however the border directory is only goiung to provide a > certificate > lookup service why use LDAP when one can use HTTP with vastly less > overhead and pain? If one is not going to support indexing and search > facilities for the certificate repository why make them available at > all? > > I would quite like to see an SRV information service of the following > form defined: > > > Service Name _SMIME-HTTP > > Protocol function: For an RFC822 address of the form > abc@xyz.com one or > more digital certificates are returned that provide a binding between > the name abc@xyz.com and one or more public keys. > > Protocol: > > 1) Obtain the SRV record _SMIME-HTTP.xyz.com > This contains the IP address a.b.c.d and the port p > > 2) Perform a retrieval query on http://a.b.c.d:p/ ? > The result of the query is the necessary S/MIME certificate (s) > > where = > "mailto:abc@xyz.com" or Base64 ( SHA1 ( "mailto:abc@xyz.com")) > (which TBD) > > where = > "something to do with specifying an acceptable certificate root" > "something to do with whether intermediate certs are required" > "something to do with the acceptable certificate format - > default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc" > "something that we thought up in the bar late one night at the > IETF" > > > My personal prefferance would be fgor the SHA1 blinded query since it > compresses the querry and emphasizes the fact that searching for names > ain't going to be a supported feature but it does not really make the > job of searching any harder in reality. > > > Phill > From owner-ietf-smime Thu May 11 09:26:29 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19204 for ietf-smime-bks; Thu, 11 May 2000 09:26:29 -0700 (PDT) Received: from ponyexpress1.csc.com (ponyexpress1.csc.com [208.219.64.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19200 for ; Thu, 11 May 2000 09:26:27 -0700 (PDT) From: rmorrill@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress1.csc.com with smtp (Exim 2.12 #1) id 12pvsN-0001wV-00; Thu, 11 May 2000 12:31:51 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568DC.005943B0 ; Thu, 11 May 2000 12:15:00 -0400 X-Lotus-FromDomain: CSC To: dennis.glatting@software-munitions.com cc: walter.williams@genuity.com, Laurent.Deffranne@dexia.be, ietf-smime@imc.org Message-ID: <852568DC.00594158.00@csc.com> Date: Thu, 11 May 2000 12:13:17 -0400 Subject: Re: Does Slime works fine with Windows 2000 PKI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One would think that if you have no control over what is shown and what is not shown, that you have effectively lost control of your LDAP systems. Which any outside anyone would love to know, competitors, recruiters, hackers. Just look at the locator info for some places over the web, you can get info down to the room number, telephone, wifes name, everything without even trying too hard. (You just have to be able to type M* to get all names with M in it). Great fun. I wonder if you could front end the whole thing via HTML/XML so any request on the LDAP or for S/Mime services would be directed to the web front end, with the proper controls? r/ Dan Morrill CSC dennis.glatting@software-munitions.com on 05/11/2000 10:35:42 AM To: walter.williams@genuity.com cc: Laurent.Deffranne@dexia.be, ietf-smime@imc.org (bcc: Ralph D Morrill/DEF/CSC) Subject: Re: Does Slime works fine with Windows 2000 PKI Walter Williams wrote: > > Active directory would expose a significant amount of information you might > not want the external world to know, such as a complete listing of all your > w2k computers and their roles in your network. You could use a LDAP proxy > server to provide what you want to the internet and keep the data in active > directory. Innosoft (Now purchased by IPlanet) makes such a product. There > are probably others on the market. > Question: Would it also disclose the name of all of the employees and their roles, something many outside recruiters would love to know? > > -----Original Message----- > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > Sent: Thursday, May 11, 2000 9:48 AM > > To: walter.williams > > Cc: ietf-smime > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > What would happen if you want to open the directory to anonymous > > access to the Web ? > > In such a way that you could exchange S/MIME certs with outside people ? > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > 11/05/2000 15:35 > > To: Laurent Deffranne/GKBCCB@GKBCCB > > cc: ietf-smime%imc.org@Internet > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > Let me take the points one at a time and inline: > > > > > -----Original Message----- > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > Sent: Thursday, May 11, 2000 9:19 AM > > > To: walter.williams > > > Cc: ietf-smime > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > Walt, > > > > > > Do you mean that there are difficulties to access through LDAP an > > > Active Directory, as you want to read or use X509 certificates ? > > > > > > > No. However, are you going to open your active directory to > > anonymous LDAP > > queries over the Internet? If not, are you limiting S/MIME to > > internal use > > only? If not then you are somewhat back to square one. > > > > > By the way,does somebody know issues about Active Directory LDAP, > > > or issues to read a certificate in an Active Directory ? > > > > This worked just fine for us here, but the problem we had with AD was that > > it does not support inetOrgPerson, and thus can't easily be > > synched up with > > most external LDAP directories. You'll find you'll want a metadirectory > > connector to synch it with any external directory. Again, this is not an > > issue if you're willing to directly expose AD to internet use. > > > > > > For me it would be a mistake to use now the "brand new" Active > > > Directory, but if someone could tell me where I can find proofs > > > of lack of compatibility (from Microsoft, there must be surely > > > one of two), this would interrest me. > > > > > AD seems to work just fine, if you don't mind working with > > something with a > > proprietary schema. Any LDAP and S/MIME aware client we pointed at it > > understood the contents just fine, so the schema does not seem to impact > > client interoperability. > > > > > Laurent > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > 11/05/2000 14:54 > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > > cc: > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Laurent; > > > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > > less so than > > > certs issued from Baltimore, Iplanet or any other CA vendor or > > > product. The > > > main issue is not will they work, but will you be able to validate the > > > certs. Unless the person issuing the cert from W2K has > > provided you with > > > their server's cert, or they have certified their CA with the > > signature of > > > the publicly known CAs you will not be able to easily verify > > the signature > > > to its source. This is not the most technically acurate way of > > > saying this > > > but I'm not awake yet. Baltimore has preregistered there CA with the > > > vendors distributing products, as has Verisign, Thaught, and > > many others. > > > Just make certain that you have the certificates for the W2K CA, > > > and access > > > to its revocation list so you can validate properly and you'll be fine. > > > > > > Walt Williams > > > TSD-Systems > > > Senior IT Analyst > > > Genuity > > > www.genuity.com > > > > > > Please note: GTE Internetworking is now Genuity. > > > > > > > -----Original Message----- > > > > From: owner-ietf-smime@mail.imc.org > > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > > > Sent: Thursday, May 11, 2000 5:45 AM > > > > To: ietf-smime > > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > Hi everybody, > > > > > > > > Just a question : > > > > > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > > > More generally, are Win2000 certificates usable with (and > > > > understood by ) the others mailers (especially Lotus Notes, > > > > Netscape, Eudora +plug-in?) > > > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > > compatibility ? > > > > > > > > Any advices are welcome. > > > > > > > > Regards, > > > > > > > > Laurent Deffranne > > > > > > > > > > > > > > > > > > -- Dennis Glatting Copyright (c) 2000 Software Munitions From owner-ietf-smime Thu May 11 10:10:42 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA19868 for ietf-smime-bks; Thu, 11 May 2000 10:10:42 -0700 (PDT) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19862 for ; Thu, 11 May 2000 10:10:36 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 11 May 00 18:27:48 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: from piers2k (host62-6-118-201.host.btclick.com [62.6.118.201] ) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id K2XJWL0R; Thu, 11 May 2000 18:11:10 +0100 Reply-to: piers@bj.co.uk From: "Piers Chivers" To: "'Laurent Deffranne'" , "'walter.williams'" cc: "'ietf-smime'" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 18:16:59 +0100 Message-ID: <000301bfbb6c$b7f2ada0$1a01a8c0@piers2k.bj.co.uk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <13F9A391AB349012*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS> X-WSS-ID: 1504321E34444-01-01 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MS have published a White Paper on Win2k PKI interoperability with other leading PKI vendor products. The WP is available on their MSDN website (can't remember where but it's called win2kpkinterop.doc). In my experience Win2k PKI is excellent as choice for an Enterprise PKI. It integrates well with AD (not surprisingly). However, as a commercial PKI the best thing that can be said about it is that it is free. And that probably sums it up succintly. Piers -----Original Message----- From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] Sent: 11 May 2000 14:19 To: walter.williams Cc: ietf-smime Subject: RE: Does Smime works fine with Windows 2000 PKI Walt, Do you mean that there are difficulties to access through LDAP an Active Directory, as you want to read or use X509 certificates ? By the way,does somebody know issues about Active Directory LDAP, or issues to read a certificate in an Active Directory ? For me it would be a mistake to use now the "brand new" Active Directory, but if someone could tell me where I can find proofs of lack of compatibility (from Microsoft, there must be surely one of two), this would interrest me. Laurent walter.williams%genuity.com@Internet 11/05/2000 14:54 To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet cc: Subject: RE: Does Smime works fine with Windows 2000 PKI Laurent; Yes, certs issued from a W2K CA can be used for S/MIME, and no less so than certs issued from Baltimore, Iplanet or any other CA vendor or product. The main issue is not will they work, but will you be able to validate the certs. Unless the person issuing the cert from W2K has provided you with their server's cert, or they have certified their CA with the signature of the publicly known CAs you will not be able to easily verify the signature to its source. This is not the most technically acurate way of saying this but I'm not awake yet. Baltimore has preregistered there CA with the vendors distributing products, as has Verisign, Thaught, and many others. Just make certain that you have the certificates for the W2K CA, and access to its revocation list so you can validate properly and you'll be fine. Walt Williams TSD-Systems Senior IT Analyst Genuity www.genuity.com Please note: GTE Internetworking is now Genuity. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > Sent: Thursday, May 11, 2000 5:45 AM > To: ietf-smime > Subject: Does Smime works fine with Windows 2000 PKI > > > Hi everybody, > > Just a question : > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > More generally, are Win2000 certificates usable with (and > understood by ) the others mailers (especially Lotus Notes, > Netscape, Eudora +plug-in?) > > Isn't Baltimore Unicert a "better choice" due to its greater > compatibility ? > > Any advices are welcome. > > Regards, > > Laurent Deffranne From owner-ietf-smime Thu May 11 09:49:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19634 for ietf-smime-bks; Thu, 11 May 2000 09:49:20 -0700 (PDT) Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19630 for ; Thu, 11 May 2000 09:49:19 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA10237; Thu, 11 May 2000 09:50:08 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 09:50:57 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EAD6@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'rmorrill@csc.com'" , dennis.glatting@software-munitions.com Cc: walter.williams@genuity.com, Laurent.Deffranne@dexia.be, ietf-smime@imc.org Subject: RE: Does Slime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 09:50:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_000B_01BFBB47.B056BD90"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BFBB47.B056BD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >One would think that if you have no control over what is shown and what is not >shown, that you have effectively lost control of your LDAP systems. Hey, misconfigured 'stuff' is a major cause of security problems. The problem I encounter very often is the cost of making sure that 'stuff' remains well configured. That is why I prefer infrastructure that is narrowly focused on a single function rather than broad-band approaches. Regarless of whether the border directory speaks LDAP or HTTP the S/MIME client still needs a way to locate it via DNS. I do not believe that the global X.500 namespace is going to ever exist and even if it did, DNS and RFC822 are the Internet namespace. Hence the SRV record is still relevant. Phill ------=_NextPart_000_000B_01BFBB47.B056BD90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE2NTE1NlowIwYJKoZI hvcNAQkEMRYEFExpKEwHGPqXRrrA+3U4fjPhKKQ7MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGABdpC8MH1fuq/l5oUTm9ImMzvXrQs9dkS4Wo4TkBQ5s505bpB/iXeOkdIeGbucAEp BAYXvR3qQOOv9w/XHZAwjibv01nSfhmRJMeY7/NKQu7pwgUd3eMgsic3B1bkiW8QhhanzxU7quin J8MKyHCo0DimFoj7fUmIfEwD6MyRIdAAAAAAAAA= ------=_NextPart_000_000B_01BFBB47.B056BD90-- From owner-ietf-smime Thu May 11 10:23:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20057 for ietf-smime-bks; Thu, 11 May 2000 10:23:19 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20053 for ; Thu, 11 May 2000 10:23:18 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id NAA16267; Thu, 11 May 2000 13:28:50 -0400 (EDT) From: "Walter Williams" To: "Philip Hallam-Baker" , "ietf-smime" Subject: RE: Border directories Date: Thu, 11 May 2000 13:19:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EAD4@vhqpostal.verisign.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The major problem I see with using HTML is the need for the email client to retrieve the public key. They are designed to do this over LDAP. Not all email clients are integrated with a HTML reader. The LDAP query is not significant overhead and checks for public key data very transparently. While SMTP and LDAP have different name spaces, it is the responsibility of the directory manager to provide a mechanism to unify the name space of the SMTP alias in the certificate with the SMTP alias available in the directory. Once this is done (rather simple actually) everything works, no matter how the DN is formatted. I strongly disagree that LDAP can not be used as an internet infrastructure by leveraging its use in the enterprise, and the market for various metadirectory products seems to back me up some what. Walt > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Philip Hallam-Baker > Sent: Thursday, May 11, 2000 11:13 AM > To: ietf-smime > Subject: Border directories > > > Re the W2K discussion: > > There is a problem with S/MIME's interaction with LDAP in general that > is certainly not unique to W2K. LDAP operates off a completely different > namespace to that of SMTP / RFC822. Furthermore there is no single > authoritative registrar for the X.500 namespace as there is for DNS (yes > I know that there are groups who claim that role but as far as I know > their authority is not generally observed). > > The application of LDAP as an enterprise infrastructure is not > compatible with its use as an internet infrastructure. An enterprise > directory has much more information than anyone is going to make > available outside the company for the likes of headhunters and > competitors. > > > The use of border directories is one possible solution. The DNS SRV > record provides a convenient means of locating a border directory. > > If however the border directory is only goiung to provide a certificate > lookup service why use LDAP when one can use HTTP with vastly less > overhead and pain? If one is not going to support indexing and search > facilities for the certificate repository why make them available at > all? > > I would quite like to see an SRV information service of the following > form defined: > > > Service Name _SMIME-HTTP > > Protocol function: For an RFC822 address of the form abc@xyz.com one or > more digital certificates are returned that provide a binding between > the name abc@xyz.com and one or more public keys. > > Protocol: > > 1) Obtain the SRV record _SMIME-HTTP.xyz.com > This contains the IP address a.b.c.d and the port p > > 2) Perform a retrieval query on http://a.b.c.d:p/ ? > The result of the query is the necessary S/MIME certificate (s) > > where = > "mailto:abc@xyz.com" or Base64 ( SHA1 ( "mailto:abc@xyz.com")) > (which TBD) > > where = > "something to do with specifying an acceptable certificate root" > "something to do with whether intermediate certs are required" > "something to do with the acceptable certificate format - > default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc" > "something that we thought up in the bar late one night at the > IETF" > > > My personal prefferance would be fgor the SHA1 blinded query since it > compresses the querry and emphasizes the fact that searching for names > ain't going to be a supported feature but it does not really make the > job of searching any harder in reality. > > > Phill > From owner-ietf-smime Thu May 11 10:19:31 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20013 for ietf-smime-bks; Thu, 11 May 2000 10:19:31 -0700 (PDT) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20009 for ; Thu, 11 May 2000 10:19:26 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 11 May 00 18:37:34 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: from piers2k (host62-6-125-135.host.btclick.com [62.6.125.135] ) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id K2XJWL09; Thu, 11 May 2000 18:20:55 +0100 Reply-to: piers@bj.co.uk From: "Piers Chivers" To: "'Walter Williams'" , "'Dennis Glatting'" cc: "'Laurent Deffranne'" , "'ietf-smime'" Subject: RE: Does Slime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 18:26:42 +0100 Message-ID: <000501bfbb6e$141c5120$1a01a8c0@piers2k.bj.co.uk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: X-WSS-ID: 1504305434501-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Win2k and hence AD has a good level of security granularity on objects and attributes that are exposed in the directory. For instance, you could configure AD to expose only the LDAP attributes that should be publicly available when a user binds anonymously (eg comes in other the Internet). Having said that, it would be a brave person who 'trusts' Win2k enough to co-locate their corporate data with public data. The proxy is probably a better idea. Piers -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Walter Williams Sent: 11 May 2000 15:39 To: Dennis Glatting Cc: Laurent Deffranne; ietf-smime Subject: RE: Does Slime works fine with Windows 2000 PKI Again, all this depends on content made available through the proxy. You can, of course require access to any directory to be over authenticated bind into the directory, but that requires maintaing a user id and pw for anyone external to your company who wants to use s/mime. This is one of the reasons for Directory sync, it allows business partners to share directory information. That is why standards compliance is an issue here, and again, active directory will require a metadirectory connector to many of the directories already deployed. Walt > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Thursday, May 11, 2000 10:36 AM > To: Walter Williams > Cc: Laurent Deffranne; ietf-smime > Subject: Re: Does Slime works fine with Windows 2000 PKI > > > Walter Williams wrote: > > > > Active directory would expose a significant amount of > information you might > > not want the external world to know, such as a complete listing > of all your > > w2k computers and their roles in your network. You could use a > LDAP proxy > > server to provide what you want to the internet and keep the > data in active > > directory. Innosoft (Now purchased by IPlanet) makes such a > product. There > > are probably others on the market. > > > > Question: > Would it also disclose the name of all of the > employees and their roles, something many > outside recruiters would love to know? > > > > > -----Original Message----- > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > Sent: Thursday, May 11, 2000 9:48 AM > > > To: walter.williams > > > Cc: ietf-smime > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > What would happen if you want to open the directory to anonymous > > > access to the Web ? > > > In such a way that you could exchange S/MIME certs with > outside people ? > > > > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > 11/05/2000 15:35 > > > To: Laurent Deffranne/GKBCCB@GKBCCB > > > cc: ietf-smime%imc.org@Internet > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Let me take the points one at a time and inline: > > > > > > > -----Original Message----- > > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > > Sent: Thursday, May 11, 2000 9:19 AM > > > > To: walter.williams > > > > Cc: ietf-smime > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > Walt, > > > > > > > > Do you mean that there are difficulties to access through LDAP an > > > > Active Directory, as you want to read or use X509 certificates ? > > > > > > > > > > No. However, are you going to open your active directory to > > > anonymous LDAP > > > queries over the Internet? If not, are you limiting S/MIME to > > > internal use > > > only? If not then you are somewhat back to square one. > > > > > > > By the way,does somebody know issues about Active Directory LDAP, > > > > or issues to read a certificate in an Active Directory ? > > > > > > This worked just fine for us here, but the problem we had > with AD was that > > > it does not support inetOrgPerson, and thus can't easily be > > > synched up with > > > most external LDAP directories. You'll find you'll want a > metadirectory > > > connector to synch it with any external directory. Again, > this is not an > > > issue if you're willing to directly expose AD to internet use. > > > > > > > > For me it would be a mistake to use now the "brand new" Active > > > > Directory, but if someone could tell me where I can find proofs > > > > of lack of compatibility (from Microsoft, there must be surely > > > > one of two), this would interrest me. > > > > > > > AD seems to work just fine, if you don't mind working with > > > something with a > > > proprietary schema. Any LDAP and S/MIME aware client we pointed at it > > > understood the contents just fine, so the schema does not > seem to impact > > > client interoperability. > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > > 11/05/2000 14:54 > > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > > > cc: > > > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > Laurent; > > > > > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > > > less so than > > > > certs issued from Baltimore, Iplanet or any other CA vendor or > > > > product. The > > > > main issue is not will they work, but will you be able to > validate the > > > > certs. Unless the person issuing the cert from W2K has > > > provided you with > > > > their server's cert, or they have certified their CA with the > > > signature of > > > > the publicly known CAs you will not be able to easily verify > > > the signature > > > > to its source. This is not the most technically acurate way of > > > > saying this > > > > but I'm not awake yet. Baltimore has preregistered there > CA with the > > > > vendors distributing products, as has Verisign, Thaught, and > > > many others. > > > > Just make certain that you have the certificates for the W2K CA, > > > > and access > > > > to its revocation list so you can validate properly and > you'll be fine. > > > > > > > > Walt Williams > > > > TSD-Systems > > > > Senior IT Analyst > > > > Genuity > > > > www.genuity.com > > > > > > > > Please note: GTE Internetworking is now Genuity. > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-smime@mail.imc.org > > > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of > Laurent Deffranne > > > > > Sent: Thursday, May 11, 2000 5:45 AM > > > > > To: ietf-smime > > > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > > > > Hi everybody, > > > > > > > > > > Just a question : > > > > > > > > > > Is there any known issues using S/MIME with > Win2000PKI-certificates ? > > > > > More generally, are Win2000 certificates usable with (and > > > > > understood by ) the others mailers (especially Lotus Notes, > > > > > Netscape, Eudora +plug-in?) > > > > > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > > > compatibility ? > > > > > > > > > > Any advices are welcome. > > > > > > > > > > Regards, > > > > > > > > > > Laurent Deffranne > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Dennis Glatting > Copyright (c) 2000 Software Munitions > From owner-ietf-smime Thu May 11 11:24:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21055 for ietf-smime-bks; Thu, 11 May 2000 11:24:16 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21051 for ; Thu, 11 May 2000 11:24:15 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA07068; Thu, 11 May 2000 14:29:41 -0400 (EDT) From: "Walter Williams" To: "Philip Hallam-Baker" , , Cc: , Subject: RE: Does Slime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 14:20:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EAD6@vhqpostal.verisign.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is why SRV records of the type _LDAP exist after all. Walt PS: Agree strongly about the security thing! > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Philip Hallam-Baker > Sent: Thursday, May 11, 2000 12:51 PM > To: 'rmorrill@csc.com'; dennis.glatting@software-munitions.com > Cc: walter.williams@genuity.com; Laurent.Deffranne@dexia.be; > ietf-smime@imc.org > Subject: RE: Does Slime works fine with Windows 2000 PKI > > > > > >One would think that if you have no control over what is shown and what > is not > >shown, that you have effectively lost control of your LDAP systems. > > Hey, misconfigured 'stuff' is a major cause of security problems. > > The problem I encounter very often is the cost of making sure that > 'stuff' remains well configured. > > That is why I prefer infrastructure that is narrowly focused on a > single function rather than broad-band approaches. > > Regarless of whether the border directory speaks LDAP or HTTP the > S/MIME client still needs a way to locate it via DNS. I do not believe > that the global X.500 namespace is going to ever exist and even if > it did, DNS and RFC822 are the Internet namespace. Hence the SRV > record is still relevant. > > Phill > From owner-ietf-smime Thu May 11 11:22:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21021 for ietf-smime-bks; Thu, 11 May 2000 11:22:28 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21016 for ; Thu, 11 May 2000 11:22:26 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA06614; Thu, 11 May 2000 14:28:37 -0400 (EDT) From: "Walter Williams" To: , , Subject: RE: Border directories Date: Thu, 11 May 2000 14:19:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <95806837902272@kahu.cs.auckland.ac.nz> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Last I checked, as the information is stored in a directory to begin with, LDAP is not a middleman, but is doing things rather directly. Doing an HTTP Get presumes that this will find it in a Directory. Probably you will find that your HTTP needs a perl cgi which actually talks LDAP behind the scenes. Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the certs are stored in a Directory. Walt > -----Original Message----- > From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] > Sent: Friday, May 12, 2000 6:06 AM > To: ietf-smime@imc.org; pbaker@verisign.com; walter.williams@genuity.com > Subject: RE: Border directories > > > "Walter Williams" writes: > > >The major problem I see with using HTML is the need for the > email client to > >retrieve the public key. They are designed to do this over > LDAP. Not all > >email clients are integrated with a HTML reader. The LDAP query is not > >significant overhead and checks for public key data very transparently. > > Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines > of code and about 5 minutes of work. When used as a > cert-grabbing mechanism, > I'd estimate that LDAP has about four orders of magnitude more > overhead (in > terms of code complexity) than HTML (probably more like five or six, going > by the size of LDAP binaries). I'm not sure what the performance > overhead is > but I can imagine that'd also be vastly higher. > > Given that in the end all you're doing is a 'SELECT cert WHERE > name = foo', > doing it via an HTTP GET makes much more sense than rewriting it into an > LDAP query in the client, communicating it via an enormously complex and > heavyweight protocol to the server, having the server rewrite it > back into > its original form so it can do something useful with it, and then > reversing > the process to return the result. Sure, you get to say "We're > using LDAP", > but wouldn't it make more sense to cut out the middleman and do things > directly? > > Peter. > From owner-ietf-smime Thu May 11 11:00:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20648 for ietf-smime-bks; Thu, 11 May 2000 11:00:27 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20641 for ; Thu, 11 May 2000 11:00:17 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA16048; Fri, 12 May 2000 06:06:19 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95806837902272>; Fri, 12 May 2000 06:06:19 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, pbaker@verisign.com, walter.williams@genuity.com Subject: RE: Border directories Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 12 May 2000 06:06:19 (NZST) Message-ID: <95806837902272@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Walter Williams" writes: >The major problem I see with using HTML is the need for the email client to >retrieve the public key. They are designed to do this over LDAP. Not all >email clients are integrated with a HTML reader. The LDAP query is not >significant overhead and checks for public key data very transparently. Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines of code and about 5 minutes of work. When used as a cert-grabbing mechanism, I'd estimate that LDAP has about four orders of magnitude more overhead (in terms of code complexity) than HTML (probably more like five or six, going by the size of LDAP binaries). I'm not sure what the performance overhead is but I can imagine that'd also be vastly higher. Given that in the end all you're doing is a 'SELECT cert WHERE name = foo', doing it via an HTTP GET makes much more sense than rewriting it into an LDAP query in the client, communicating it via an enormously complex and heavyweight protocol to the server, having the server rewrite it back into its original form so it can do something useful with it, and then reversing the process to return the result. Sure, you get to say "We're using LDAP", but wouldn't it make more sense to cut out the middleman and do things directly? Peter. From owner-ietf-smime Thu May 11 11:26:37 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21095 for ietf-smime-bks; Thu, 11 May 2000 11:26:37 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21087 for ; Thu, 11 May 2000 11:26:33 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA18072; Fri, 12 May 2000 06:32:36 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95806995603561>; Fri, 12 May 2000 06:32:36 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, pbaker@verisign.com, pgut001@cs.aucKland.ac.nz, walter.williams@genuity.com Subject: RE: Border directories Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 12 May 2000 06:32:36 (NZST) Message-ID: <95806995603561@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Walter Williams" writes: >Last I checked, as the information is stored in a directory to begin with, Last I checked all the LDAP directories I could find used either Berkeley DB or an RDBMS to store information. With LDAP you have: client -> LDAP (client) -> LDAP (server) -> RDBMS What I was suggesting is: client -> HTTP GET -> RDBMS cutting out the superfluous LDAP bloat in the middle. Peter. From owner-ietf-smime Thu May 11 11:19:33 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA20970 for ietf-smime-bks; Thu, 11 May 2000 11:19:33 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20966 for ; Thu, 11 May 2000 11:19:28 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA05456; Thu, 11 May 2000 14:25:18 -0400 (EDT) From: "Walter Williams" To: "Philip Hallam-Baker" , "ietf-smime" Subject: RE: Border directories Date: Thu, 11 May 2000 14:15:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EAD9@vhqpostal.verisign.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The lovely thing about directories is that they can be chained rather easily (Netscape as an exception here but that is one of the reasons Sun bought Innosoft) so if you have access to one directory, that one might be chained to one hundred and you would never know it. I obviously need to give you access to my directory to make this work. Directories have not been over sold, they've been under implemented. That is changing fast. Walt > -----Original Message----- > From: Philip Hallam-Baker [mailto:pbaker@verisign.com] > Sent: Thursday, May 11, 2000 1:49 PM > To: 'Walter Williams'; Philip Hallam-Baker; ietf-smime > Subject: RE: Border directories > > > HTTP, not HTML. An HTTP retrieval protocol can be written in 100 > lines by any competent coder in less than a day. > > And no, the email clients ability to do this over LDAP is not > currently enough. My email client will not locate your cert because > it is chained to only 8 directories. > > There is a need for email clients to be able to use SRV records to > locate directories. > > > My problem is not with the LDAP technology though but the market > understanding thereof. Directories have been vastly oversold as > a panacea for every IT problem. > > Phill > > -----Original Message----- > From: Walter Williams [mailto:walter.williams@genuity.com] > Sent: Thursday, May 11, 2000 1:19 PM > To: Philip Hallam-Baker; ietf-smime > Subject: RE: Border directories > > > The major problem I see with using HTML is the need for the email client > to > retrieve the public key. They are designed to do this over LDAP. Not > all > email clients are integrated with a HTML reader. The LDAP query is not > significant overhead and checks for public key data very transparently. > > While SMTP and LDAP have different name spaces, it is the responsibility > of > the directory manager to provide a mechanism to unify the name space of > the > SMTP alias in the certificate with the SMTP alias available in the > directory. Once this is done (rather simple actually) everything works, > no > matter how the DN is formatted. > > I strongly disagree that LDAP can not be used as an internet > infrastructure > by leveraging its use in the enterprise, and the market for various > metadirectory products seems to back me up some what. > > Walt > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Philip Hallam-Baker > > Sent: Thursday, May 11, 2000 11:13 AM > > To: ietf-smime > > Subject: Border directories > > > > > > Re the W2K discussion: > > > > There is a problem with S/MIME's interaction with LDAP in general that > > is certainly not unique to W2K. LDAP operates off a completely > different > > namespace to that of SMTP / RFC822. Furthermore there is no single > > authoritative registrar for the X.500 namespace as there is for DNS > (yes > > I know that there are groups who claim that role but as far as I know > > their authority is not generally observed). > > > > The application of LDAP as an enterprise infrastructure is not > > compatible with its use as an internet infrastructure. An enterprise > > directory has much more information than anyone is going to make > > available outside the company for the likes of headhunters and > > competitors. > > > > > > The use of border directories is one possible solution. The DNS SRV > > record provides a convenient means of locating a border directory. > > > > If however the border directory is only goiung to provide a > certificate > > lookup service why use LDAP when one can use HTTP with vastly less > > overhead and pain? If one is not going to support indexing and search > > facilities for the certificate repository why make them available at > > all? > > > > I would quite like to see an SRV information service of the following > > form defined: > > > > > > Service Name _SMIME-HTTP > > > > Protocol function: For an RFC822 address of the form abc@xyz.com one > or > > more digital certificates are returned that provide a binding between > > the name abc@xyz.com and one or more public keys. > > > > Protocol: > > > > 1) Obtain the SRV record _SMIME-HTTP.xyz.com > > This contains the IP address a.b.c.d and the port p > > > > 2) Perform a retrieval query on http://a.b.c.d:p/ ? > > The result of the query is the necessary S/MIME certificate (s) > > > > where = > > "mailto:abc@xyz.com" or Base64 ( SHA1 ( "mailto:abc@xyz.com")) > > (which TBD) > > > > where = > > "something to do with specifying an acceptable certificate root" > > "something to do with whether intermediate certs are required" > > "something to do with the acceptable certificate format - > > default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc" > > "something that we thought up in the bar late one night at the > > IETF" > > > > > > My personal prefferance would be fgor the SHA1 blinded query since it > > compresses the querry and emphasizes the fact that searching for names > > ain't going to be a supported feature but it does not really make the > > job of searching any harder in reality. > > > > > > Phill > > > From owner-ietf-smime Thu May 11 11:41:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21311 for ietf-smime-bks; Thu, 11 May 2000 11:41:10 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21306 for ; Thu, 11 May 2000 11:41:05 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA13447; Thu, 11 May 2000 14:47:22 -0400 (EDT) From: "Walter Williams" To: , , Subject: RE: Border directories Date: Thu, 11 May 2000 14:37:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <95806995603561@kahu.cs.auckland.ac.nz> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Unfortunately for your model, there are a variety of directory vendors which do not store in either Berkeley DB or in a RDBMS datastore. Microsoft is one. Novell another, Lotus a third. There are others. LDAP is certainly less overhead than MAPI or what ever Novell's and Lotus's equivilent API would be. And LDAP is already built into the client to do exactly what you are asking some one to write code to do. Yes it can be done. Yes it will be done. But most are doing this through LDAP for very good reasons. Keep in mind that many email clients do not do HTTP, so then you would have a flow path of: to create s/mime email, don't create a new email in client, open browser, browse to proper link, run query, have email aware http application you have to now write create your email. This application should idealy call your default email package, but how will it tell Outlook as an example about the certificate it just found? I can't see that as a natural flow of work. Yes, if you are using an web based email service such as hotmail. No if you are using a corporate solution. Walt > -----Original Message----- > From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] > Sent: Friday, May 12, 2000 6:33 AM > To: ietf-smime@imc.org; pbaker@verisign.com; pgut001@cs.auckland.ac.nz; > walter.williams@genuity.com > Subject: RE: Border directories > > > "Walter Williams" writes: > > >Last I checked, as the information is stored in a directory to > begin with, > > Last I checked all the LDAP directories I could find used either > Berkeley DB or an RDBMS to store information. With LDAP you have: > > client -> LDAP (client) -> LDAP (server) -> RDBMS > > What I was suggesting is: > > client -> HTTP GET -> RDBMS > > cutting out the superfluous LDAP bloat in the middle. > > Peter. > From owner-ietf-smime Thu May 11 11:29:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA21165 for ietf-smime-bks; Thu, 11 May 2000 11:29:45 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21161 for ; Thu, 11 May 2000 11:29:43 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA09379; Thu, 11 May 2000 14:36:01 -0400 (EDT) From: "Walter Williams" To: , "'Laurent Deffranne'" Cc: "'ietf-smime'" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Thu, 11 May 2000 14:26:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <000301bfbb6c$b7f2ada0$1a01a8c0@piers2k.bj.co.uk> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Free only if you own Windows 2000, but yes that means free for most folks eventually. However, most of the costs associated with a PKI are not in the actual technology, but rather in the legal side of things. Outsourcing to a CA vendor such as Baltimore, Entrust or Verisign allows you to offset the soft costs to a company which has already done its legal home work for you. There is a lot of discussion on the cost/benefits on inhousing a CA which can be found in EMA sessions, often available on www.ema.org. Also look at www.pki.org for interoperability testing (not just white papers here). EMA has recently published the findings of a large test regarding PKI interop which involved many vendors, the federal government and this is available again at www.ema.org. I don't know if the tests have included W2K in the past but we can ask Microsoft to participate as they are an ongoing process. Walt > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Piers Chivers > Sent: Thursday, May 11, 2000 1:17 PM > To: 'Laurent Deffranne'; 'walter.williams' > Cc: 'ietf-smime' > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > MS have published a White Paper on Win2k PKI interoperability with other > leading PKI vendor products. The WP is available on their MSDN website > (can't remember where but it's called win2kpkinterop.doc). > > In my experience Win2k PKI is excellent as choice for an > Enterprise PKI. It > integrates well with AD (not surprisingly). However, as a commercial PKI > the best thing that can be said about it is that it is free. And that > probably sums it up succintly. > > Piers > > -----Original Message----- > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > Sent: 11 May 2000 14:19 > To: walter.williams > Cc: ietf-smime > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > Walt, > > Do you mean that there are difficulties to access through LDAP an Active > Directory, as you want to read or use X509 certificates ? > > By the way,does somebody know issues about Active Directory LDAP, or > issues to read a certificate in an Active Directory ? > > For me it would be a mistake to use now the "brand new" Active > Directory, but if someone could tell me where I can find proofs of lack > of compatibility (from Microsoft, there must be surely one of two), this > would interrest me. > > Laurent > > > > > > walter.williams%genuity.com@Internet > 11/05/2000 14:54 > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > cc: > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > Laurent; > > Yes, certs issued from a W2K CA can be used for S/MIME, and no less so > than > certs issued from Baltimore, Iplanet or any other CA vendor or product. > The > main issue is not will they work, but will you be able to validate the > certs. Unless the person issuing the cert from W2K has provided you > with > their server's cert, or they have certified their CA with the signature > of > the publicly known CAs you will not be able to easily verify the > signature > to its source. This is not the most technically acurate way of saying > this > but I'm not awake yet. Baltimore has preregistered there CA with the > vendors distributing products, as has Verisign, Thaught, and many > others. > Just make certain that you have the certificates for the W2K CA, and > access > to its revocation list so you can validate properly and you'll be fine. > > Walt Williams > TSD-Systems > Senior IT Analyst > Genuity > www.genuity.com > > Please note: GTE Internetworking is now Genuity. > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > Sent: Thursday, May 11, 2000 5:45 AM > > To: ietf-smime > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > Hi everybody, > > > > Just a question : > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > More generally, are Win2000 certificates usable with (and > > understood by ) the others mailers (especially Lotus Notes, > > Netscape, Eudora +plug-in?) > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > compatibility ? > > > > Any advices are welcome. > > > > Regards, > > > > Laurent Deffranne > > > > > From owner-ietf-smime Thu May 11 10:43:33 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20388 for ietf-smime-bks; Thu, 11 May 2000 10:43:33 -0700 (PDT) Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20384 for ; Thu, 11 May 2000 10:43:32 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA16052; Thu, 11 May 2000 10:49:35 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 10:48:36 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EAD9@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Walter Williams'" , Philip Hallam-Baker , ietf-smime Subject: RE: Border directories Date: Thu, 11 May 2000 10:48:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_003E_01BFBB4F.C00FE1A0"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_003E_01BFBB4F.C00FE1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HTTP, not HTML. An HTTP retrieval protocol can be written in 100 lines by any competent coder in less than a day. And no, the email clients ability to do this over LDAP is not currently enough. My email client will not locate your cert because it is chained to only 8 directories. There is a need for email clients to be able to use SRV records to locate directories. My problem is not with the LDAP technology though but the market understanding thereof. Directories have been vastly oversold as a panacea for every IT problem. Phill -----Original Message----- From: Walter Williams [mailto:walter.williams@genuity.com] Sent: Thursday, May 11, 2000 1:19 PM To: Philip Hallam-Baker; ietf-smime Subject: RE: Border directories The major problem I see with using HTML is the need for the email client to retrieve the public key. They are designed to do this over LDAP. Not all email clients are integrated with a HTML reader. The LDAP query is not significant overhead and checks for public key data very transparently. While SMTP and LDAP have different name spaces, it is the responsibility of the directory manager to provide a mechanism to unify the name space of the SMTP alias in the certificate with the SMTP alias available in the directory. Once this is done (rather simple actually) everything works, no matter how the DN is formatted. I strongly disagree that LDAP can not be used as an internet infrastructure by leveraging its use in the enterprise, and the market for various metadirectory products seems to back me up some what. Walt > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Philip Hallam-Baker > Sent: Thursday, May 11, 2000 11:13 AM > To: ietf-smime > Subject: Border directories > > > Re the W2K discussion: > > There is a problem with S/MIME's interaction with LDAP in general that > is certainly not unique to W2K. LDAP operates off a completely different > namespace to that of SMTP / RFC822. Furthermore there is no single > authoritative registrar for the X.500 namespace as there is for DNS (yes > I know that there are groups who claim that role but as far as I know > their authority is not generally observed). > > The application of LDAP as an enterprise infrastructure is not > compatible with its use as an internet infrastructure. An enterprise > directory has much more information than anyone is going to make > available outside the company for the likes of headhunters and > competitors. > > > The use of border directories is one possible solution. The DNS SRV > record provides a convenient means of locating a border directory. > > If however the border directory is only goiung to provide a certificate > lookup service why use LDAP when one can use HTTP with vastly less > overhead and pain? If one is not going to support indexing and search > facilities for the certificate repository why make them available at > all? > > I would quite like to see an SRV information service of the following > form defined: > > > Service Name _SMIME-HTTP > > Protocol function: For an RFC822 address of the form abc@xyz.com one or > more digital certificates are returned that provide a binding between > the name abc@xyz.com and one or more public keys. > > Protocol: > > 1) Obtain the SRV record _SMIME-HTTP.xyz.com > This contains the IP address a.b.c.d and the port p > > 2) Perform a retrieval query on http://a.b.c.d:p/ ? > The result of the query is the necessary S/MIME certificate (s) > > where = > "mailto:abc@xyz.com" or Base64 ( SHA1 ( "mailto:abc@xyz.com")) > (which TBD) > > where = > "something to do with specifying an acceptable certificate root" > "something to do with whether intermediate certs are required" > "something to do with the acceptable certificate format - > default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc" > "something that we thought up in the bar late one night at the > IETF" > > > My personal prefferance would be fgor the SHA1 blinded query since it > compresses the querry and emphasizes the fact that searching for names > ain't going to be a supported feature but it does not really make the > job of searching any harder in reality. > > > Phill > ------=_NextPart_000_003E_01BFBB4F.C00FE1A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE3NDkzOFowIwYJKoZI hvcNAQkEMRYEFED2oou8rKfKGUcIObn7Bc0cckvqMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAckMScqqaTEAci8NgcZMCS3dI1yIWeKCQpJvtPEwBzigabYOKG6ueMDXLJKGdBktG heNVanGreH+XLFl+pjw779Rhy90t/UO4cjxl8QN/ZCuyvIfqEwL42CeVEvvZ9bEFltLzrMZvnv8H NqlVi67S5hliT9XNPMeVHti6u0l+szEAAAAAAAA= ------=_NextPart_000_003E_01BFBB4F.C00FE1A0-- From owner-ietf-smime Thu May 11 12:16:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21995 for ietf-smime-bks; Thu, 11 May 2000 12:16:53 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21990 for ; Thu, 11 May 2000 12:16:50 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA18638; Fri, 12 May 2000 07:22:53 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95807297303945>; Fri, 12 May 2000 07:22:53 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, pbaker@verisign.com, pgut001@cs.aucKland.ac.nz, walter.williams@genuity.com Subject: RE: Border directories Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 12 May 2000 07:22:53 (NZST) Message-ID: <95807297303945@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Walter Williams" writes: >And LDAP is already built into the client to do exactly what you are asking >some one to write code to do. Yes it can be done. Yes it will be done. >But most are doing this through LDAP for very good reasons. Keep in mind >that many email clients do not do HTTP, so then you would have a flow path >of: to create s/mime email, don't create a new email in client, open browser, >browse to proper link, run query, have email aware http application you have >to now write create your email. This application should idealy call your >default email package, but how will it tell Outlook as an example about the >certificate it just found? I can't see that as a natural flow of work. >Yes, if you are using an web based email service such as hotmail. No if you >are using a corporate solution. Just because it's possible to push a pea up a mountain with your nose doesn't mean that that's the best way to get it there. Certainly if you go with this amazing inverted world view in which 10 lines of code added to an existing TCP/IP-aware app is more work than integrating a multimegabyte LDAP client library with its enormously complex programming interface and config requirements, then LDAP is simpler and easier than HTTP. In my world however, doing it via HTTP from the email client would be the easier option (although it's certainly possible to invent arbitrarily awkward scenarios for HTTP if your goal is to make LDAP look good in comparison). Peter. From owner-ietf-smime Thu May 11 19:18:09 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA10349 for ietf-smime-bks; Thu, 11 May 2000 19:18:09 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10344 for ; Thu, 11 May 2000 19:18:07 -0700 (PDT) Received: from wwilliams4 (wwilliams1.bbn.com [128.33.211.196]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id WAA08227; Thu, 11 May 2000 22:23:57 -0400 (EDT) From: "Walter Williams" To: , , Subject: RE: Border directories Date: Thu, 11 May 2000 22:14:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01BFBB96.441F8C70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <95807297303945@kahu.cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BFBB96.441F8C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Peter, The problem of your model is you presume two things that don't exist: uniformity in data store behind the directory and uniformity in access control. LDAP exists, as does DAP (the OSI heavier Directory Access Protocol which LDAP somewhat replaced) to provide uniformity in data access when you know nothing about the data store, but you know what you want. Under your model, you would have to write different HTTP applets for each different backend. They would need to authenticate with the back end, using a mechanism which is proprietary. LDAP handles the authentication, makes it as strong (need a cert to bind) or as week (anonymous bind) as you need, and returns the same set of data from no matter how it is stored in no matter what database. LDAP is not all things for all people, but it does allow email systems to quickly access data regarding people including but not limited to their public key. It also allows the users to quickly find a person's email alias and their public key and Use it to create a encrypted or just signed message. By the way, I can retrieve a user's certificate and any other relevant data in about 10 lines of properly written LDAP code in either C, Perl, or Java. Why you keep on talking about megabytes of code, I don't know. I would recommend you to read up on the standard and its API. Coding LDAP is as simple as coding HTTP. Perhaps you are confusing the LDAP Protocol with SLAPD, the LDAP based Directory. While the directory is indeed megabytes of code, the API is rather small, the relevant .JAR files for java take up a cumulative 60 kb or so, I can't imagine the C libraries are any bigger, if anything I would imagine that they are smaller. I would recommend that if you feel that what you propose is so superior that you write up some IETF Drafts and try to productize your ideas. See how well they sell. If you're right, you'll make a fortune. Lets kill this thread as it is getting us no where. The initial questions have nothing to do with the use of LDAP as an API or directory access mechanism, and you seem to be a little misinformed about what LDAP is and how it is used. Walt Williams TSD-Systems Senior IT Analyst Genuity www.genuity.com Please note: GTE Internetworking is now Genuity. > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Peter Gutmann > Sent: Friday, May 12, 2000 7:23 AM > To: ietf-smime@imc.org; pbaker@verisign.com; pgut001@cs.aucKland.ac.nz; > walter.williams@genuity.com > Subject: RE: Border directories > > > "Walter Williams" writes: > > >And LDAP is already built into the client to do exactly what you > are asking > >some one to write code to do. Yes it can be done. Yes it will > be done. > >But most are doing this through LDAP for very good reasons. > Keep in mind > >that many email clients do not do HTTP, so then you would have a > flow path > >of: to create s/mime email, don't create a new email in client, > open browser, > >browse to proper link, run query, have email aware http > application you have > >to now write create your email. This application should idealy > call your > >default email package, but how will it tell Outlook as an > example about the > >certificate it just found? I can't see that as a natural flow of work. > >Yes, if you are using an web based email service such as > hotmail. No if you > >are using a corporate solution. > > Just because it's possible to push a pea up a mountain with your > nose doesn't > mean that that's the best way to get it there. Certainly if you > go with this > amazing inverted world view in which 10 lines of code added to an > existing > TCP/IP-aware app is more work than integrating a multimegabyte LDAP client > library with its enormously complex programming interface and config > requirements, then LDAP is simpler and easier than HTTP. In my > world however, > doing it via HTTP from the email client would be the easier > option (although > it's certainly possible to invent arbitrarily awkward scenarios > for HTTP if > your goal is to make LDAP look good in comparison). > > Peter. > ------=_NextPart_000_0004_01BFBB96.441F8C70 Content-Type: text/x-vcard; name="Walter B Williams.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Walter B Williams.vcf" BEGIN:VCARD VERSION:2.1 N:Williams;Walter;B;Mr. FN:Walter B Williams NICKNAME:Walt ORG:Genuity Inc.;TSD TITLE:Senior IT Analyst TEL;WORK;VOICE:617-873-5888 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;2/221B;50 Moulton St=3D0D=3D0AMS = 2/2A;Cambridge;MA;02138;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:2/221B=3D0D=3D0A50 Moulton = St=3D0D=3D0AMS 2/2A=3D0D=3D0ACambridge, MA 02138=3D0D=3D0AUSA URL: URL:http://www.genuity.com EMAIL;PREF;INTERNET:walter.williams@genuity.com REV:20000407T003737Z END:VCARD ------=_NextPart_000_0004_01BFBB96.441F8C70-- From owner-ietf-smime Fri May 12 02:41:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA13336 for ietf-smime-bks; Fri, 12 May 2000 02:41:32 -0700 (PDT) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA13310 for ; Fri, 12 May 2000 02:41:01 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 12 May 00 10:59:03 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id ; Fri, 12 May 2000 10:42:29 +0100 Message-ID: <608D67882786D211B1070090271E4CB94813D9@BJEX1> From: "Stuart Ross" To: "'pgut001@cs.aucKland.ac.nz'" , ietf-smime@imc.org, pbaker@verisign.com, walter.williams@genuity.com Subject: RE: Border directories Date: Fri, 12 May 2000 10:42:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 15050A6D1020-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBBF6.63333534" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBBF6.63333534 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Peter, I am with Walter on this one, whether LDAP is implemented at the client or at the server you are going to need it in their somewhere, certificates are stored in a directory that exposes its data via LDAP and some form of LDAP interface will be required between the Directory and web server. Yes you can use HTTP to retrieve certificates but this is not the way the market has gone, all of the major SMIME clients available on the market today will retrieve certificates using the LDAP protocol quickly and efficiently, off course this has the added advantage that all directories should support LDAP, not all companies that you will communicate with will have tied their directory to a web server. Stuart Ross -----Original Message----- From: pgut001@cs.aucKland.ac.nz [mailto:pgut001@cs.aucKland.ac.nz] Sent: Friday, May 12, 2000 7:06 AM To: ietf-smime@imc.org; pbaker@verisign.com; walter.williams@genuity.com Subject: RE: Border directories "Walter Williams" writes: >The major problem I see with using HTML is the need for the email client to >retrieve the public key. They are designed to do this over LDAP. Not all >email clients are integrated with a HTML reader. The LDAP query is not >significant overhead and checks for public key data very transparently. Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines of code and about 5 minutes of work. When used as a cert-grabbing mechanism, I'd estimate that LDAP has about four orders of magnitude more overhead (in terms of code complexity) than HTML (probably more like five or six, going by the size of LDAP binaries). I'm not sure what the performance overhead is but I can imagine that'd also be vastly higher. Given that in the end all you're doing is a 'SELECT cert WHERE name = foo', doing it via an HTTP GET makes much more sense than rewriting it into an LDAP query in the client, communicating it via an enormously complex and heavyweight protocol to the server, having the server rewrite it back into its original form so it can do something useful with it, and then reversing the process to return the result. Sure, you get to say "We're using LDAP", but wouldn't it make more sense to cut out the middleman and do things directly? Peter. ------_=_NextPart_001_01BFBBF6.63333534 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable RE: Border directories

Peter,

I am with Walter on this one, whether LDAP is = implemented at the client or at the server you are going to need it in = their somewhere, certificates are stored in a directory that exposes = its data via LDAP and some form of LDAP interface will be required = between the Directory and web server. Yes you can use HTTP to retrieve = certificates but this is not the way the market has gone, all of the = major SMIME clients available on the market today will retrieve = certificates using the LDAP protocol quickly and efficiently, off = course this has the added advantage that all directories should support = LDAP, not all companies that you will communicate with will have tied = their directory to a web server.

Stuart Ross
-----Original Message-----
From: pgut001@cs.aucKland.ac.nz [mailto:pgut001@cs.aucKland.ac.= nz]
Sent: Friday, May 12, 2000 7:06 AM
To: ietf-smime@imc.org; pbaker@verisign.com; = walter.williams@genuity.com
Subject: RE: Border directories


"Walter Williams" = <walter.williams@genuity.com> writes:

>The major problem I see with using HTML is the = need for the email client to
>retrieve the public key.  They are designed = to do this over LDAP.  Not all
>email clients are integrated with a HTML = reader.  The LDAP query is not
>significant overhead and checks for public key = data very transparently.

Uhh... anything which can talk TCP/IP can do an HTML = GET in about 10 lines
of code and about 5 minutes of work.  When used = as a cert-grabbing mechanism,
I'd estimate that LDAP has about four orders of = magnitude more overhead (in
terms of code complexity) than HTML (probably more = like five or six, going
by the size of LDAP binaries).  I'm not sure = what the performance overhead is
but I can imagine that'd also be vastly = higher.

Given that in the end all you're doing is a 'SELECT = cert WHERE name =3D foo',
doing it via an HTTP GET makes much more sense than = rewriting it into an
LDAP query in the client, communicating it via an = enormously complex and
heavyweight protocol to the server, having the = server rewrite it back into
its original form so it can do something useful with = it, and then reversing
the process to return the result.  Sure, you = get to say "We're using LDAP",
but wouldn't it make more sense to cut out the = middleman and do things
directly?

Peter.

------_=_NextPart_001_01BFBBF6.63333534-- From owner-ietf-smime Fri May 12 03:07:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA14538 for ietf-smime-bks; Fri, 12 May 2000 03:07:56 -0700 (PDT) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA14532 for ; Fri, 12 May 2000 03:07:52 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 12 May 00 11:26:00 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id ; Fri, 12 May 2000 11:09:26 +0100 Message-ID: <608D67882786D211B1070090271E4CB94813DC@BJEX1> From: "Stuart Ross" To: "'pgut001@cs.aucKland.ac.nz'" cc: "'ietf-smime@imc.org'" , "'pbaker@verisign.com'" , "'pgut001@cs.aucKland.ac.nz'" , "'walter.williams@genuity.com'" Subject: RE: Border directories Date: Fri, 12 May 2000 11:09:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 150503B21222-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBBFA.26B7EACE" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBBFA.26B7EACE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Peter, LDAP stands for LIGHTWEIGHT Directory Access protocol and is by its very nature efficient with an extremely low footprint, for example we have available an LDAP COM Automation server that can be used to tie an LDAP directory to a web server and has a footprint of < 1 MB. This aside if you had to code HTTP requests into an SMIME client that could do all of the functions that an LDAP SMIME client can do then I suspect you would find the HTTP code growing and growing. Stuart Ross -----Original Message----- From: pgut001@cs.aucKland.ac.nz [mailto:pgut001@cs.aucKland.ac.nz] Sent: Friday, May 12, 2000 8:23 AM To: ietf-smime@imc.org; pbaker@verisign.com; pgut001@cs.aucKland.ac.nz; walter.williams@genuity.com Subject: RE: Border directories "Walter Williams" writes: >And LDAP is already built into the client to do exactly what you are asking >some one to write code to do. Yes it can be done. Yes it will be done. >But most are doing this through LDAP for very good reasons. Keep in mind >that many email clients do not do HTTP, so then you would have a flow path >of: to create s/mime email, don't create a new email in client, open browser, >browse to proper link, run query, have email aware http application you have >to now write create your email. This application should idealy call your >default email package, but how will it tell Outlook as an example about the >certificate it just found? I can't see that as a natural flow of work. >Yes, if you are using an web based email service such as hotmail. No if you >are using a corporate solution. Just because it's possible to push a pea up a mountain with your nose doesn't mean that that's the best way to get it there. Certainly if you go with this amazing inverted world view in which 10 lines of code added to an existing TCP/IP-aware app is more work than integrating a multimegabyte LDAP client library with its enormously complex programming interface and config requirements, then LDAP is simpler and easier than HTTP. In my world however, doing it via HTTP from the email client would be the easier option (although it's certainly possible to invent arbitrarily awkward scenarios for HTTP if your goal is to make LDAP look good in comparison). Peter. ------_=_NextPart_001_01BFBBFA.26B7EACE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable RE: Border directories

Peter,

LDAP stands for LIGHTWEIGHT Directory Access protocol = and is by its very nature efficient with an extremely low footprint, = for example we have available an LDAP COM Automation server that can be = used to tie an LDAP directory to a web server and has a footprint of = < 1 MB. This aside if you had to code HTTP requests into an SMIME = client that could do all of the functions that an LDAP SMIME client can = do then I suspect you would find the HTTP code growing and = growing.

Stuart Ross
-----Original Message-----
From: pgut001@cs.aucKland.ac.nz [mailto:pgut001@cs.aucKland.ac.= nz]
Sent: Friday, May 12, 2000 8:23 AM
To: ietf-smime@imc.org; pbaker@verisign.com; = pgut001@cs.aucKland.ac.nz;
walter.williams@genuity.com
Subject: RE: Border directories


"Walter Williams" = <walter.williams@genuity.com> writes:

>And LDAP is already built into the client to do = exactly what you are asking
>some one to write code to do.  Yes it can = be done.  Yes it will be done. 
>But most are doing this through LDAP for very = good reasons.  Keep in mind
>that many email clients do not do HTTP, so then = you would have a flow path
>of: to create s/mime email, don't create a new = email in client, open browser,
>browse to proper link, run query, have email = aware http application you have
>to now write create your email.  This = application should idealy call your
>default email package, but how will it tell = Outlook as an example about the
>certificate it just found?  I can't see = that as a natural flow of work. 
>Yes, if you are using an web based email service = such as hotmail.  No if you
>are using a corporate solution.

Just because it's possible to push a pea up a = mountain with your nose doesn't
mean that that's the best way to get it there.  = Certainly if you go with this
amazing inverted world view in which 10 lines of = code added to an existing
TCP/IP-aware app is more work than integrating a = multimegabyte LDAP client
library with its enormously complex programming = interface and config
requirements, then LDAP is simpler and easier than = HTTP.  In my world however,
doing it via HTTP from the email client would be the = easier option (although
it's certainly possible to invent arbitrarily = awkward scenarios for HTTP if
your goal is to make LDAP look good in = comparison).

Peter.

------_=_NextPart_001_01BFBBFA.26B7EACE-- From owner-ietf-smime Fri May 12 02:47:29 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA13601 for ietf-smime-bks; Fri, 12 May 2000 02:47:29 -0700 (PDT) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA13586 for ; Fri, 12 May 2000 02:47:24 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 12 May 00 11:05:33 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id ; Fri, 12 May 2000 10:48:59 +0100 Message-ID: <608D67882786D211B1070090271E4CB94813DA@BJEX1> From: "Stuart Ross" To: "'Walter Williams'" , "Piers Chivers" , "'Laurent Deffranne'" cc: "'ietf-smime'" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Fri, 12 May 2000 10:48:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 150508E71069-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBBF7.4BCEA1D4" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBBF7.4BCEA1D4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Ongoing costs play the largest part in the cost of a PKI, for example issuing Certificates, revoking certificates, rolling over certificates, supporting users etc, the list goes on and it is non trivial, therefore expensive either outsourcing or in-house. Stuart R -----Original Message----- From: Walter Williams [mailto:walter.williams@genuity.com] Sent: Thursday, May 11, 2000 7:26 PM To: piers@bj.co.uk; 'Laurent Deffranne' Cc: 'ietf-smime' Subject: RE: Does Smime works fine with Windows 2000 PKI Free only if you own Windows 2000, but yes that means free for most folks eventually. However, most of the costs associated with a PKI are not in the actual technology, but rather in the legal side of things. Outsourcing to a CA vendor such as Baltimore, Entrust or Verisign allows you to offset the soft costs to a company which has already done its legal home work for you. There is a lot of discussion on the cost/benefits on inhousing a CA which can be found in EMA sessions, often available on www.ema.org. Also look at www.pki.org for interoperability testing (not just white papers here). EMA has recently published the findings of a large test regarding PKI interop which involved many vendors, the federal government and this is available again at www.ema.org. I don't know if the tests have included W2K in the past but we can ask Microsoft to participate as they are an ongoing process. Walt > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Piers Chivers > Sent: Thursday, May 11, 2000 1:17 PM > To: 'Laurent Deffranne'; 'walter.williams' > Cc: 'ietf-smime' > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > MS have published a White Paper on Win2k PKI interoperability with other > leading PKI vendor products. The WP is available on their MSDN website > (can't remember where but it's called win2kpkinterop.doc). > > In my experience Win2k PKI is excellent as choice for an > Enterprise PKI. It > integrates well with AD (not surprisingly). However, as a commercial PKI > the best thing that can be said about it is that it is free. And that > probably sums it up succintly. > > Piers > > -----Original Message----- > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > Sent: 11 May 2000 14:19 > To: walter.williams > Cc: ietf-smime > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > Walt, > > Do you mean that there are difficulties to access through LDAP an Active > Directory, as you want to read or use X509 certificates ? > > By the way,does somebody know issues about Active Directory LDAP, or > issues to read a certificate in an Active Directory ? > > For me it would be a mistake to use now the "brand new" Active > Directory, but if someone could tell me where I can find proofs of lack > of compatibility (from Microsoft, there must be surely one of two), this > would interrest me. > > Laurent > > > > > > walter.williams%genuity.com@Internet > 11/05/2000 14:54 > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > cc: > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > Laurent; > > Yes, certs issued from a W2K CA can be used for S/MIME, and no less so > than > certs issued from Baltimore, Iplanet or any other CA vendor or product. > The > main issue is not will they work, but will you be able to validate the > certs. Unless the person issuing the cert from W2K has provided you > with > their server's cert, or they have certified their CA with the signature > of > the publicly known CAs you will not be able to easily verify the > signature > to its source. This is not the most technically acurate way of saying > this > but I'm not awake yet. Baltimore has preregistered there CA with the > vendors distributing products, as has Verisign, Thaught, and many > others. > Just make certain that you have the certificates for the W2K CA, and > access > to its revocation list so you can validate properly and you'll be fine. > > Walt Williams > TSD-Systems > Senior IT Analyst > Genuity > www.genuity.com > > Please note: GTE Internetworking is now Genuity. > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > Sent: Thursday, May 11, 2000 5:45 AM > > To: ietf-smime > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > Hi everybody, > > > > Just a question : > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > More generally, are Win2000 certificates usable with (and > > understood by ) the others mailers (especially Lotus Notes, > > Netscape, Eudora +plug-in?) > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > compatibility ? > > > > Any advices are welcome. > > > > Regards, > > > > Laurent Deffranne > > > > > ------_=_NextPart_001_01BFBBF7.4BCEA1D4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable RE: Does Smime works fine with Windows 2000 PKI

Ongoing costs play the largest part in the cost of a = PKI, for example issuing Certificates, revoking certificates, rolling = over certificates, supporting users etc, the list goes on and it is non = trivial, therefore expensive either outsourcing or in-house. =

Stuart R
 
-----Original Message-----
From: Walter Williams [mailto:walter.williams@genui= ty.com]
Sent: Thursday, May 11, 2000 7:26 PM
To: piers@bj.co.uk; 'Laurent Deffranne'
Cc: 'ietf-smime'
Subject: RE: Does Smime works fine with Windows 2000 = PKI


Free only if you own Windows 2000, but yes that means = free for most folks
eventually.  However, most of the costs = associated with a PKI are not in the
actual technology, but rather in the legal side of = things.  Outsourcing to a
CA vendor such as Baltimore, Entrust or Verisign = allows you to offset the
soft costs to a company which has already done its = legal home work for you.
There is a lot of discussion on the cost/benefits on = inhousing a CA which
can be found in EMA sessions, often available on = www.ema.org.  Also look at
www.pki.org for interoperability testing (not just = white papers here).  EMA
has recently published the findings of a large test = regarding PKI interop
which involved many vendors, the federal government = and this is available
again at www.ema.org.  I don't know if the = tests have included W2K in the
past but we can ask Microsoft to participate as they = are an ongoing process.

Walt

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
> [mailto:owner-ietf-smime@ma= il.imc.org]On Behalf Of Piers Chivers
> Sent: Thursday, May 11, 2000 1:17 PM
> To: 'Laurent Deffranne'; = 'walter.williams'
> Cc: 'ietf-smime'
> Subject: RE: Does Smime works fine with Windows = 2000 PKI
>
>
> MS have published a White Paper on Win2k PKI = interoperability with other
> leading PKI vendor products.  The WP is = available on their MSDN website
> (can't remember where but it's called = win2kpkinterop.doc).
>
> In my experience Win2k PKI is excellent as = choice for an
> Enterprise PKI.  It
> integrates well with AD (not = surprisingly).  However, as a commercial PKI
> the best thing that can be said about it is = that it is free.  And that
> probably sums it up succintly.
>
> Piers
>
> -----Original Message-----
> From: Laurent Deffranne [mailto:Laurent.Deffranne@dexi= a.be]
> Sent: 11 May 2000 14:19
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows = 2000 PKI
>
>
> Walt,
>
> Do you mean that there are difficulties to = access through LDAP an Active
> Directory, as you want to read or use X509 = certificates ?
>
> By the way,does somebody know issues about = Active Directory LDAP, or
> issues to read a certificate in an Active = Directory ?
>
> For me it would be a mistake to use now the = "brand new" Active
> Directory, but if someone could tell me where I = can find proofs of lack
> of compatibility (from Microsoft, there must be = surely one of two), this
> would interrest me.
>
> Laurent
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 14:54
> To:   Laurent = Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> cc:
>
> Subject:      RE: Does = Smime works fine with Windows 2000 PKI
>
> Laurent;
>
> Yes, certs issued from a W2K CA can be used for = S/MIME, and no less so
> than
> certs issued from Baltimore, Iplanet or any = other CA vendor or product.
> The
> main issue is not will they work, but will you = be able to validate the
> certs.  Unless the person issuing the cert = from W2K has provided you
> with
> their server's cert, or they have certified = their CA with the signature
> of
> the publicly known CAs you will not be able to = easily verify the
> signature
> to its source.  This is not the most = technically acurate way of saying
> this
> but I'm not awake yet.  Baltimore has = preregistered there CA with the
> vendors distributing products, as has Verisign, = Thaught, and many
> others.
> Just make certain that you have the = certificates for the W2K CA, and
> access
> to its revocation list so you can validate = properly and you'll be fine.
>
> Walt Williams
> TSD-Systems
> Senior IT Analyst
> Genuity
> www.genuity.com
>
> Please note: GTE Internetworking is now = Genuity.
>
> > -----Original Message-----
> > From: owner-ietf-smime@mail.imc.org
> > [mailto:owner-ietf-smime@ma= il.imc.org]On Behalf Of Laurent Deffranne
> > Sent: Thursday, May 11, 2000 5:45 = AM
> > To: ietf-smime
> > Subject: Does Smime works fine with = Windows 2000 PKI
> >
> >
> > Hi everybody,
> >
> > Just a question :
> >
> > Is there any known issues using S/MIME = with Win2000PKI-certificates ?
> > More generally, are Win2000 certificates = usable with (and
> > understood by ) the others mailers = (especially Lotus Notes,
> > Netscape, Eudora +plug-in?)
> >
> > Isn't Baltimore Unicert a "better = choice" due to its greater
> > compatibility ?
> >
> > Any advices are welcome.
> >
> > Regards,
> >
> > Laurent Deffranne
>
>
>
>
>

------_=_NextPart_001_01BFBBF7.4BCEA1D4-- From owner-ietf-smime Fri May 12 07:02:18 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23516 for ietf-smime-bks; Fri, 12 May 2000 07:02:18 -0700 (PDT) Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23512 for ; Fri, 12 May 2000 07:02:17 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA13536; Fri, 12 May 2000 07:07:49 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 07:06:50 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F43EA73D@vhqpostal.verisign.com> From: Philip Hallam-Baker To: Walter Williams , pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org, pbaker@verisign.com Subject: RE: Border directories Date: Fri, 12 May 2000 07:06:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFBBA2.F60F30F0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BFBBA2.F60F30F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >Last I checked, as the information is stored in a directory to begin with, >LDAP is not a middleman, but is doing things rather directly. LDAP is just a protocol, all protocols are middlemen >Doing an HTTP >Get presumes that this will find it in a Directory. Probably you will find >that your HTTP needs a perl cgi which actually talks LDAP behind the scenes. More likely talk to a database. I was never a fan of either CGI or Perl. >Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the certs >are stored in a Directory. Who says so??? They are wrong in many cases. Phill ------=_NextPart_000_0000_01BFBBA2.F60F30F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjAzNDUxN1owIwYJKoZI hvcNAQkEMRYEFOqSplfwmXLZmrEPc4YSJypgLzozMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAbToJbzvGboMoOFPCOLRCFntvQyI63VlFZ21bZNhMSpakE4o3Q4G3KkmHbb5i2C5m KRDfpXYN7jZpnORm/PR1ZwZ7C+RwH/Nl4MyQJS+S2JohZ1u7e3952z9N18k3uVR1f+YiwZmlDgpV cTrzk4AM0He6Q5EfBkuKcF2DGwN9bLoAAAAAAAA= ------=_NextPart_000_0000_01BFBBA2.F60F30F0-- From owner-ietf-smime Fri May 12 07:02:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23521 for ietf-smime-bks; Fri, 12 May 2000 07:02:19 -0700 (PDT) Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23517 for ; Fri, 12 May 2000 07:02:18 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA10483; Fri, 12 May 2000 07:06:03 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 07:06:53 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F43EA73E@vhqpostal.verisign.com> From: Philip Hallam-Baker To: Walter Williams , piers@bj.co.uk, "'Laurent Deffranne'" Cc: "'ietf-smime'" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Fri, 12 May 2000 07:06:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0005_01BFBBA4.40D932B0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFBBA4.40D932B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit I think that the hidden costs of using Cert server was what Peter was referring to when he said 'free was the best thing to be said about it'... The purchase cost of enterprise infrastructure software is rarely a significant factor in the total cost of deployment. I am not aware that all PKI vendors 'do the legal work for you' however. In fact some specialist PKI vendors do no more than Microsoft, they deliver software in shrink wrapped boxes... Phill -----Original Message----- From: Walter Williams [mailto:walter.williams@genuity.com] Sent: Thursday, May 11, 2000 2:26 PM To: piers@bj.co.uk; 'Laurent Deffranne' Cc: 'ietf-smime' Subject: RE: Does Smime works fine with Windows 2000 PKI Free only if you own Windows 2000, but yes that means free for most folks eventually. However, most of the costs associated with a PKI are not in the actual technology, but rather in the legal side of things. Outsourcing to a CA vendor such as Baltimore, Entrust or Verisign allows you to offset the soft costs to a company which has already done its legal home work for you. There is a lot of discussion on the cost/benefits on inhousing a CA which can be found in EMA sessions, often available on www.ema.org. Also look at www.pki.org for interoperability testing (not just white papers here). EMA has recently published the findings of a large test regarding PKI interop which involved many vendors, the federal government and this is available again at www.ema.org. I don't know if the tests have included W2K in the past but we can ask Microsoft to participate as they are an ongoing process. Walt > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Piers Chivers > Sent: Thursday, May 11, 2000 1:17 PM > To: 'Laurent Deffranne'; 'walter.williams' > Cc: 'ietf-smime' > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > MS have published a White Paper on Win2k PKI interoperability with other > leading PKI vendor products. The WP is available on their MSDN website > (can't remember where but it's called win2kpkinterop.doc). > > In my experience Win2k PKI is excellent as choice for an > Enterprise PKI. It > integrates well with AD (not surprisingly). However, as a commercial PKI > the best thing that can be said about it is that it is free. And that > probably sums it up succintly. > > Piers > > -----Original Message----- > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > Sent: 11 May 2000 14:19 > To: walter.williams > Cc: ietf-smime > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > Walt, > > Do you mean that there are difficulties to access through LDAP an Active > Directory, as you want to read or use X509 certificates ? > > By the way,does somebody know issues about Active Directory LDAP, or > issues to read a certificate in an Active Directory ? > > For me it would be a mistake to use now the "brand new" Active > Directory, but if someone could tell me where I can find proofs of lack > of compatibility (from Microsoft, there must be surely one of two), this > would interrest me. > > Laurent > > > > > > walter.williams%genuity.com@Internet > 11/05/2000 14:54 > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > cc: > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > Laurent; > > Yes, certs issued from a W2K CA can be used for S/MIME, and no less so > than > certs issued from Baltimore, Iplanet or any other CA vendor or product. > The > main issue is not will they work, but will you be able to validate the > certs. Unless the person issuing the cert from W2K has provided you > with > their server's cert, or they have certified their CA with the signature > of > the publicly known CAs you will not be able to easily verify the > signature > to its source. This is not the most technically acurate way of saying > this > but I'm not awake yet. Baltimore has preregistered there CA with the > vendors distributing products, as has Verisign, Thaught, and many > others. > Just make certain that you have the certificates for the W2K CA, and > access > to its revocation list so you can validate properly and you'll be fine. > > Walt Williams > TSD-Systems > Senior IT Analyst > Genuity > www.genuity.com > > Please note: GTE Internetworking is now Genuity. > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > Sent: Thursday, May 11, 2000 5:45 AM > > To: ietf-smime > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > Hi everybody, > > > > Just a question : > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > More generally, are Win2000 certificates usable with (and > > understood by ) the others mailers (especially Lotus Notes, > > Netscape, Eudora +plug-in?) > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > compatibility ? > > > > Any advices are welcome. > > > > Regards, > > > > Laurent Deffranne > > > > > ------=_NextPart_000_0005_01BFBBA4.40D932B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjAzNTQzMlowIwYJKoZI hvcNAQkEMRYEFNTMUOluu1fjEtV9dmhuUxErV2SHMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAlucBtBuqN90uuReSkBH/JFyPTi2mIs7fCQWIzIFBdxixm9mtUKV6QsgpTvqzX83Y SZxW5UlIm9phYAv34Kq07ua0mvjkWpXiBydELOFVSOCOnq9xjohn9L/OMKe3DtA1p6NwG/ausbN7 VbtveaCXJtaSYm6g1+vzn8aaYoIP5vcAAAAAAAA= ------=_NextPart_000_0005_01BFBBA4.40D932B0-- From owner-ietf-smime Fri May 12 07:17:33 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23773 for ietf-smime-bks; Fri, 12 May 2000 07:17:33 -0700 (PDT) Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23769 for ; Fri, 12 May 2000 07:17:32 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA14211 for ; Fri, 12 May 2000 07:23:41 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 07:22:42 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EADD@vhqpostal.verisign.com> From: Philip Hallam-Baker To: ietf-smime@imc.org Subject: RE: Border directories Date: Fri, 12 May 2000 07:22:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0009_01BFBBFC.28435FC0"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01BFBBFC.28435FC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit >>certificates are stored in a directory that exposes its data >>via LDAP and some form of LDAP interface will be required Dead wrong. Sometimes this is the case but it is neither necessarily the case or even usually the case. LDAP is simply an access protocol. There is no necessity that LDAP be involved AT ALL in the Certificate repository. Of course to interface to many PKI applications it is usefull to support LDAP as one option, but the idea that it is impossible to access data directly through a repository interface to HTTP, FTP or even Gopher without converting the protocol to LDAP and back is simply incorrect. >>we have available an LDAP COM Automation server that can be used >>to tie an LDAP directory to a web server and has a footprint of >> < 1 MB. Yeah, LIGHTWEIGHT! Try fitting that on a Palm VII! How about a smartcard? I don't know quite how we got into this argument. I am certainly not trying to dis LDAP, far from it, I was very involved in the VeriSign LDAP strategy. All I am trying to say is that the LDAP protocol did not close forever the question of where certificates are to reside and the access protocols by which they are to be retrieved. If companies cannot be persuaded to deploy border directories that talk LDAP we can try them on HTTP. If they won't take HTTP we can invent something else altogether. Phill ------=_NextPart_000_0009_01BFBBFC.28435FC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjE0MjM0N1owIwYJKoZI hvcNAQkEMRYEFJ28Y033HZ25s2lOUIqdH+jgObbDMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAIj1J/TvYQymbMry8Fxccp1YarsRvFEs0udf4Z9lU4KQ9Tvrr72CF1Ca0nsoCtF8N Qqys4qMdZY4pA+9KxQI9za1bl3qdbjkyQ3kqOyynyzzGC50nS2uXPmB66iIqZ0Tj/oYpSoAUwsUl CjKkWQykuGn5UoO7NUsBO9NELk2EGX0AAAAAAAA= ------=_NextPart_000_0009_01BFBBFC.28435FC0-- From owner-ietf-smime Fri May 12 08:12:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25031 for ietf-smime-bks; Fri, 12 May 2000 08:12:08 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25023 for ; Fri, 12 May 2000 08:12:06 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id LAA19855; Fri, 12 May 2000 11:17:44 -0400 (EDT) From: "Walter Williams" To: "Philip Hallam-Baker" , , , Subject: RE: Border directories Date: Fri, 12 May 2000 11:08:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F43EA73D@vhqpostal.verisign.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: True, certs can be and often are stored as files in file servers. This does not make them easy for an email client to find them. We were talking about S/MIME and Active Directory. The W2K cert server can store the certs in a Directory by default, one which is LDAP accessible and that is exactly what the email client needs. I never said that certs could only be stored in a directory, but in this discussion, founded on the question of W2K and S/MIME interoperability, a directory is precisely where you'll find them. Since active directory is not something most companies will want to expose to the internet, I proposed a directory proxy. You are also right, LDAP is a middleman, but only in the same way HTTP is. Unfortunately, your quoting of my text does not properly quote Peter's. Please lets drop these threads, they loose the context of the original discussion which was on interoperability. Walt > -----Original Message----- > From: Philip Hallam-Baker [mailto:pbaker@verisign.com] > Sent: Friday, May 12, 2000 10:07 AM > To: Walter Williams; pgut001@cs.auckland.ac.nz; ietf-smime@imc.org; > pbaker@verisign.com > Subject: RE: Border directories > > > > >Last I checked, as the information is stored in a directory to begin > with, > >LDAP is not a middleman, but is doing things rather directly. > > LDAP is just a protocol, all protocols are middlemen > > >Doing an HTTP > >Get presumes that this will find it in a Directory. Probably you will > find > >that your HTTP needs a perl cgi which actually talks LDAP behind the > scenes. > > More likely talk to a database. > > I was never a fan of either CGI or Perl. > > >Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the > certs > >are stored in a Directory. > > Who says so??? They are wrong in many cases. > > > Phill > From owner-ietf-smime Fri May 12 08:14:09 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25054 for ietf-smime-bks; Fri, 12 May 2000 08:14:09 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25050 for ; Fri, 12 May 2000 08:14:08 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id LAA20631; Fri, 12 May 2000 11:19:54 -0400 (EDT) From: "Walter Williams" To: "Philip Hallam-Baker" , , "'Laurent Deffranne'" Cc: "'ietf-smime'" Subject: RE: Does Smime works fine with Windows 2000 PKI Date: Fri, 12 May 2000 11:10:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F43EA73E@vhqpostal.verisign.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I never said all CA vendors do the legal work but I listed three who do. Legal work is a hugh hidden cost and risk of PKI. Please do not put words im my mouth. Walter > -----Original Message----- > From: Philip Hallam-Baker [mailto:pbaker@verisign.com] > Sent: Friday, May 12, 2000 10:07 AM > To: Walter Williams; piers@bj.co.uk; 'Laurent Deffranne' > Cc: 'ietf-smime' > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > I think that the hidden costs of using Cert server was what Peter > was referring to when he said 'free was the best thing to be said > about it'... > > The purchase cost of enterprise infrastructure software is rarely > a significant factor in the total cost of deployment. I am not aware > that all PKI vendors 'do the legal work for you' however. In fact > some specialist PKI vendors do no more than Microsoft, they deliver > software in shrink wrapped boxes... > > Phill > > -----Original Message----- > From: Walter Williams [mailto:walter.williams@genuity.com] > Sent: Thursday, May 11, 2000 2:26 PM > To: piers@bj.co.uk; 'Laurent Deffranne' > Cc: 'ietf-smime' > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > Free only if you own Windows 2000, but yes that means free for most folks > eventually. However, most of the costs associated with a PKI are not in > the > actual technology, but rather in the legal side of things. Outsourcing to > a > CA vendor such as Baltimore, Entrust or Verisign allows you to offset the > soft costs to a company which has already done its legal home work for > you. > There is a lot of discussion on the cost/benefits on inhousing a CA which > can be found in EMA sessions, often available on www.ema.org. Also look > at > www.pki.org for interoperability testing (not just white papers here). > EMA > has recently published the findings of a large test regarding PKI interop > which involved many vendors, the federal government and this is available > again at www.ema.org. I don't know if the tests have included W2K in the > past but we can ask Microsoft to participate as they are an ongoing > process. > > Walt > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Piers Chivers > > Sent: Thursday, May 11, 2000 1:17 PM > > To: 'Laurent Deffranne'; 'walter.williams' > > Cc: 'ietf-smime' > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > MS have published a White Paper on Win2k PKI interoperability with other > > leading PKI vendor products. The WP is available on their MSDN website > > (can't remember where but it's called win2kpkinterop.doc). > > > > In my experience Win2k PKI is excellent as choice for an > > Enterprise PKI. It > > integrates well with AD (not surprisingly). However, as a commercial > PKI > > the best thing that can be said about it is that it is free. And that > > probably sums it up succintly. > > > > Piers > > > > -----Original Message----- > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > Sent: 11 May 2000 14:19 > > To: walter.williams > > Cc: ietf-smime > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Walt, > > > > Do you mean that there are difficulties to access through LDAP an Active > > Directory, as you want to read or use X509 certificates ? > > > > By the way,does somebody know issues about Active Directory LDAP, or > > issues to read a certificate in an Active Directory ? > > > > For me it would be a mistake to use now the "brand new" Active > > Directory, but if someone could tell me where I can find proofs of lack > > of compatibility (from Microsoft, there must be surely one of two), this > > would interrest me. > > > > Laurent > > > > > > > > > > > > walter.williams%genuity.com@Internet > > 11/05/2000 14:54 > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > cc: > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > Laurent; > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no less so > > than > > certs issued from Baltimore, Iplanet or any other CA vendor or product. > > The > > main issue is not will they work, but will you be able to validate the > > certs. Unless the person issuing the cert from W2K has provided you > > with > > their server's cert, or they have certified their CA with the signature > > of > > the publicly known CAs you will not be able to easily verify the > > signature > > to its source. This is not the most technically acurate way of saying > > this > > but I'm not awake yet. Baltimore has preregistered there CA with the > > vendors distributing products, as has Verisign, Thaught, and many > > others. > > Just make certain that you have the certificates for the W2K CA, and > > access > > to its revocation list so you can validate properly and you'll be fine. > > > > Walt Williams > > TSD-Systems > > Senior IT Analyst > > Genuity > > www.genuity.com > > > > Please note: GTE Internetworking is now Genuity. > > > > > -----Original Message----- > > > From: owner-ietf-smime@mail.imc.org > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne > > > Sent: Thursday, May 11, 2000 5:45 AM > > > To: ietf-smime > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > Hi everybody, > > > > > > Just a question : > > > > > > Is there any known issues using S/MIME with Win2000PKI-certificates ? > > > More generally, are Win2000 certificates usable with (and > > > understood by ) the others mailers (especially Lotus Notes, > > > Netscape, Eudora +plug-in?) > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > compatibility ? > > > > > > Any advices are welcome. > > > > > > Regards, > > > > > > Laurent Deffranne > > > > > > > > > > > From owner-ietf-smime Fri May 12 08:19:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25172 for ietf-smime-bks; Fri, 12 May 2000 08:19:48 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25168 for ; Fri, 12 May 2000 08:19:47 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA01396 for ; Fri, 12 May 2000 11:21:34 -0400 (EDT) Message-Id: <200005121521.LAA01392@roadblock.missi.ncsc.mil> Date: Fri, 12 May 2000 11:24:14 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Border directories To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: c9yL/76h5kk9tWZa3I1ujw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Aren't you leaving out both a block and an assumption in the HTTP path? The assumptions are that the DSA not only is based on an RDBMS but that the RDBMS interface is exposed to other applications. If these assumptions are true, the paths would be more like: client -> LDAP client -> LDAP server ---------\ \ RDBMS / client -> HTTP GET -> Apache w/mod_perl & DBI-/ It's not obvious that an HTTP server with a DB interface can be made to have a smaller footprint than an LDAP server with a DB interface, or that server footprint is even a useful metric. I'd be more concerned with transaction response time as a function of offered load, using identical hardware. More importantly, the assumption that DSAs are generally based on RDBMS backends is not obviously valid - directories and RDBMSs have different strengths. Implementing one as an interface to the other, though possible, is not likely to win any performance benchmarks. Perhaps a few DSA vendors will chime in here with some ground truth on RDBMS usage and API accessability to 3rd party apps. Dave > From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) > > > "Walter Williams" writes: > > >Last I checked, as the information is stored in a directory to begin with, > > Last I checked all the LDAP directories I could find used either > Berkeley DB or an RDBMS to store information. With LDAP you have: > > client -> LDAP (client) -> LDAP (server) -> RDBMS > > What I was suggesting is: > > client -> HTTP GET -> RDBMS > > cutting out the superfluous LDAP bloat in the middle. > > Peter. From owner-ietf-smime Fri May 12 08:50:27 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25869 for ietf-smime-bks; Fri, 12 May 2000 08:50:27 -0700 (PDT) Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25865 for ; Fri, 12 May 2000 08:50:26 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA17431; Fri, 12 May 2000 08:56:24 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 08:55:25 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EADF@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'David P. Kemp'" , ietf-smime@imc.org Subject: RE: Border directories Date: Fri, 12 May 2000 08:55:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0014_01BFBC07.FC77DD10"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BFBC07.FC77DD10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >> client -> HTTP GET -> Apache w/mod_perl & DBI-/ Perl? Puleeezzee... I am not a fan of the RDBMS model either... But basing a design decision on the 'Fact' that HTTP has to involve a shell scripting language with a somewhat eccentric syntax rather than a direct call to the databes API is somewhat odd in any case. All you need in the repository is ACID properties. Insisting that the choice of data model must be either RDB or X.500 is somewhat odd IMNSHO. The only data model you actually need is that required by the S/MIME client interface and the PKI interface. i.e. retrieval by means of a key formed by the subjectAltName (or legacy DN component) and incremental addition/deletion of certificates and CRLs by the PKI data source. Oh and by the way, folk making statements about Active directory as if it was simply and exclusively an LDAP directory make a major underestimation of its function and capabilities. Phill ------=_NextPart_000_0014_01BFBC07.FC77DD10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjE1NDgyN1owIwYJKoZI hvcNAQkEMRYEFCdWJOTg0Mn6FSkWc64Zzcj3dvlGMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAfkukUuFUF/bsWt/xX9WLRoCtr5zddTSW+J9HZvBIOT/FEPmuZ6rZfL/ZTnjndpII wJZYMivdpcvqQkq37qhR00LGl2sjYF1KcnKA21NP5kzK10iCIBjYru2x/13swe+IpVwZnkOIq9LO iFfazwYlnFPSBIrAJLr7FYU0CEOMAyAAAAAAAAA= ------=_NextPart_000_0014_01BFBC07.FC77DD10-- From owner-ietf-smime Fri May 12 09:01:20 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26053 for ietf-smime-bks; Fri, 12 May 2000 09:01:20 -0700 (PDT) Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [193.63.53.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26044 for ; Fri, 12 May 2000 09:01:15 -0700 (PDT) Received: from crusader (actually host crusader.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (Mailer); Fri, 12 May 2000 17:07:04 +0100 Reply-To: "Colin.Robbins" From: Colin Robbins To: "'David P. Kemp'" , ietf-smime Subject: RE: Border directories Date: Fri, 12 May 2000 17:07:01 +0100 Message-ID: <003901bfbc2c$1c5e0590$ea353fc1@nexor.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200005121521.LAA01392@roadblock.missi.ncsc.mil> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > More importantly, the assumption that DSAs are generally > based on RDBMS > backends is not obviously valid - directories and RDBMSs have > different > strengths. Implementing one as an interface to the other, though > possible, is not likely to win any performance benchmarks. Perhaps > a few DSA vendors will chime in here with some ground truth on RDBMS > usage and API accessability to 3rd party apps. > There is an assumption that because a DSA is based on a RDBMS, you can use RDBMS tools to access the data directly. This is a false assumption. Due to the mismatch between Directory requirements and a RDBMS, directory vendors using a RDBMS generally have to write an interface layer to map data between directory constructs and RDBMS constructs. This generally means the data in the RDBMS is structured to meet the directory needs, and not other application needs. As such, using third party RDBMS tools becomes very difficult - the data is not is an easily-usable form. If anyone is interested in the technical reasons why a RDBMS is bad news for directory performance, then there is a white paper " Use of OODB Technology for Directories" written by an independent expert on our web site (http://www.nexor.com/info/papers.htm) that describes these problems in detail. NEXOR's own DSA is fundamentally not based on a RDBMS due to these problems. If you want to access data in a Directory, then the only reliable method is to use Directory APIs, as provided by the directory vendors. In addition to understanding the data structure, they also know about application constraints. For example access control. Going direct to a RDBMS is likely to bypass any application access controls provided by the Directory vendor. Colin From owner-ietf-smime Fri May 12 10:16:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27272 for ietf-smime-bks; Fri, 12 May 2000 10:16:48 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27267 for ; Fri, 12 May 2000 10:16:45 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA14617 for ; Sat, 13 May 2000 05:22:53 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95815217312068>; Sat, 13 May 2000 05:22:53 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: RE: Border directories Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 13 May 2000 05:22:53 (NZST) Message-ID: <95815217312068@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Walter Williams" writes: >Lets kill this thread as it is getting us no where. I agree, any attempt at further debate seems pointless. However, I'm willing to extend the following olive branch: I you can give me a 10-line RFC 1823- compliant C program to fetch certificates from an LDAP directory as per your previous message, then I'm prepared to admit that everything I've said is wrong and everything you've said (that all MTA's support LDAP and none of them apparently support TCP/IP (which is what's required to do an HTTP GET), necessitating the use of an external web browser to fetch certs, etc etc) is right. Deal? (Incidentally, to the person who claimed that their <1MB LDAP client is "lightweight", you may have a future working for Oracle's marketing division, since their <1MB client is frequently criticised as being unnecessarily bloated and heavyweight. I'd also recommend contacting the editors of the Oxford English Dictionary so they can correct their definition of "lightweight", perhaps US dictionaries define this word differently than our ones do). Peter (exits, shaking head in disbelief). From owner-ietf-smime Fri May 12 10:30:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27434 for ietf-smime-bks; Fri, 12 May 2000 10:30:17 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27430 for ; Fri, 12 May 2000 10:30:15 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA15790; Sat, 13 May 2000 05:36:15 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95815297512191>; Sat, 13 May 2000 05:36:15 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: dpkemp@missi.ncsc.mil, ietf-smime@imc.org Subject: RE: Border directories Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 13 May 2000 05:36:15 (NZST) Message-ID: <95815297512191@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: (Phew, back to technical discussions at last)... >Aren't you leaving out both a block and an assumption in the HTTP path? > >The assumptions are that the DSA not only is based on an RDBMS but that the >RDBMS interface is exposed to other applications. If these assumptions are >true, the paths would be more like: > > client -> LDAP client -> LDAP server ---------\ > \ > RDBMS > / > client -> HTTP GET -> Apache w/mod_perl & DBI-/ Why would you need to run Apache? The model I was using was: client -> socket read -> server stub -> RDBMS Every RDBMS vendor on the planet either has or is making their database web-aware (although for security purposes I'd prefer to stick my own stub in front of it because I don't trust anyone to get things like this right :-). The interface is incredibly trivial, using a speed-optimised database like MySQL (which doesn't have a "lightweight" client like, say, Oracle), the server stub isn't more than a page or two of code (bind to a socket, read requests, drop them into a line of SQL, then call mysql_query() and mysql_use_result()/fetch_row() and send the result back to the caller. I'm sure I could crank it out in a hour or so (although MySQL does have web glue built in if you want to go that way and use the native capabilities). Total extra overhead in the client (assuming it already speaks SMTP, which one can probably assume for a mail client): One read and one write call. Total overhead in the server: An accept(), a read, the aforementioned RDBMS glue code, and a write for the results. You can even use the standard dictionary definition of lightweight to desribe that. It makes for a very nice, simple "gimme a cert" protocol without the bloat and overhead of other alternatives. Peter. From owner-ietf-smime Fri May 12 10:37:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27527 for ietf-smime-bks; Fri, 12 May 2000 10:37:56 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27520 for ; Fri, 12 May 2000 10:37:54 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA14512; Sat, 13 May 2000 05:43:42 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95815342211633>; Sat, 13 May 2000 05:43:42 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: Colin.Robbins@nexor.com, dpkemp@missi.ncsc.mil, ietf-smime@imc.org Subject: RE: Border directories Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 13 May 2000 05:43:42 (NZST) Message-ID: <95815342211633@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Colin Robbins writes: >If anyone is interested in the technical reasons why a RDBMS is bad news for >directory performance, then there is a white paper " Use of OODB Technology >for Directories" written by an independent expert on our web site >(http://www.nexor.com/info/papers.htm) that describes these problems in >detail. And OpenDirectory claim the exact opposite on their site :-). I'm actually surprised Alan Lloyd hasn't chimed in with his perspective on LDAP yet. Peter. From owner-ietf-smime Fri May 12 10:05:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27130 for ietf-smime-bks; Fri, 12 May 2000 10:05:16 -0700 (PDT) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27126 for ; Fri, 12 May 2000 10:05:15 -0700 (PDT) Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id NAA26404; Fri, 12 May 2000 13:11:08 -0400 (EDT) From: "Walter Williams" To: "Philip Hallam-Baker" , "'David P. Kemp'" , Subject: RE: Border directories Date: Fri, 12 May 2000 13:01:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EADF@vhqpostal.verisign.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Oh and by the way, folk making statements about Active directory > as if it was simply and exclusively an LDAP directory make > a major underestimation of its function and capabilities. > > Phill But the other capacities were outside the context of our discussion on interoperability with S/MIME and therefor out of scope. I try not to waste people's time with fluf and am again calling that this thread be snuffed. It has lost any and all relevance to the initial discussions. From owner-ietf-smime Fri May 12 16:31:00 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA02661 for ietf-smime-bks; Fri, 12 May 2000 16:31:00 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02657 for ; Fri, 12 May 2000 16:30:59 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 12 May 2000 17:36:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 12 May 2000 17:36:16 -0600 From: "Bob Jueneman" To: , , Subject: RE: Border directories Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_B5ED9D6D.395892DF" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_B5ED9D6D.395892DF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Three brief technical points: 1. At least with respect to Novell's 8th generation directory, NDS, LDAP = is=20 an access protocol that is supported natively by the directory engine. =20 So you can use NDAP (Novell's variant of the standard X.500 DAP, for=20 reasons I won't go into), or you can use the not particularly light-weight,= =20 but arguably light-functionality LDAP interface. It makes no difference to = us,=20 as we support both. 2. NDS is based on a Novell-proprietary "arbitrarily-structured data = base",=20 NOT on an RDBMS. That's why the directory is as small as it is, and = yet=20 has the scalability and performance it does. Although other Novell = applications=20 can use the same underlying database technology (the GroupWise message server does), they do not share the same database. So David's assumptions are incorrect, at least with respect to one = major=20 DSA provider. That's not to say that you couldn't publish certificates in = a=20 web server and access them via http, independent of any directory. You = could. =20 You could even synchronize the web server and the directory using our=20 DirXML capability, if you chose to. But you don't access the underlying=20= database while it may be undergoing synchronization, replication, backup, repair, etc., etc., under the control of the higher level application, = about=20 which the other application would know nothing. 3. The much more significant point, unless I've overlooked a=20 "directoryCapabilities" attribute in the S/MIME spec somewhere , is = that=20 both the originating and receiving application are completely clueless=20 as to where to find either the directory itself, or the http provider. Once I use mental telephathy to figure out the DSN name of the server=20 where the user chose to publish his certificates(s), then I can start = rummaging=20 around though either LDAP or HTTP, trying to guess the schema, and = which=20 index to use to locate that user's certificate. Those are the points we ought to be focussing on, IMHO. Bob >>> Peter Gutmann 05/13/00 05:36AM >>> "David P. Kemp" writes: (Phew, back to technical discussions at last)... >Aren't you leaving out both a block and an assumption in the HTTP path? > >The assumptions are that the DSA not only is based on an RDBMS but that = the=20 >RDBMS interface is exposed to other applications. If these assumptions = are=20 >true, the paths would be more like: > > client -> LDAP client -> LDAP server ---------\ > \ > RDBMS > / > client -> HTTP GET -> Apache w/mod_perl & DBI-/ Why would you need to run Apache? The model I was using was: client -> socket read -> server stub -> RDBMS Every RDBMS vendor on the planet either has or is making their database web-aware (although for security purposes I'd prefer to stick my own stub = in front of it because I don't trust anyone to get things like this right = :-). The interface is incredibly trivial, using a speed-optimised database like MySQL (which doesn't have a "lightweight" client like, say, Oracle), = the=20 server stub isn't more than a page or two of code (bind to a socket, read requests, drop them into a line of SQL, then call mysql_query() and=20 mysql_use_result()/fetch_row() and send the result back to the caller. = I'm sure I could crank it out in a hour or so (although MySQL does have web = glue built in if you want to go that way and use the native capabilities). Total extra overhead in the client (assuming it already speaks SMTP, = which=20 one can probably assume for a mail client): One read and one write call. Total overhead in the server: An accept(), a read, the aforementioned = RDBMS glue code, and a write for the results. You can even use the standard dictionary definition of lightweight to = desribe=20 that. It makes for a very nice, simple "gimme a cert" protocol without = the bloat and overhead of other alternatives. Peter. --=_B5ED9D6D.395892DF Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Three brief technical points:
 
1.  At least with respect to Novell's 8th = generation=20 directory, NDS, LDAP is
an access protocol that is suppor= ted=20 natively by the directory engine. 
So you can use NDAP (Novell's var= iant of=20 the standard X.500 DAP, for
reasons I won't go into), or you can use the not particularly light-weight,
but arguably light-functionality LDAP interface. = It makes no difference to us,
as we support both.
 
2.  NDS is based on a Novell-proprietary=20 "arbitrarily-structured data base",
NOT on an RDBMS.  That's = why the=20 directory is as small as it is, and yet
has the scalability and = performance it=20 does. Although other Novell applications
can use the same underlying datab= ase=20 technology (the GroupWise message
server does), they do not share the same=20 database.
 
So David's assumptions are incorrect, at least with = respect to=20 one major
DSA provider.  That's not = to say that=20 you couldn't publish certificates in a
web server and access them via ht= tp,=20 independent of any directory.  You could. 
You could even synchronize the web server and the = directory using our
DirXML capability, if you chose to.  But you = don't access=20 the underlying
database while it may be undergoing synchronization,=20= replication, backup,
 repair, etc., etc., under = the=20 control of the higher level application, about
which the other application would know=20 nothing.
 
3.  The much more significant point, unless = I've=20 overlooked a
"directoryCapabilities"  att= ribute in=20 the S/MIME spec somewhere , is that
both the originating and receiving application = are completely clueless
as to where to find either the directory = itself, or the=20 http provider.
 
Once I use mental telephathy to figure out the DSN = name of the=20 server
where the user chose to publish = his=20 certificates(s), then I can start rummaging
around though either = LDAP=20 or HTTP, trying to guess the schema, and which =
index to use to locate that = user's=20 certificate.
 
Those are the points we ought to be focussing on,=20 IMHO.
 
Bob
 
 
>>> Peter Gutmann <pgut001@cs.aucKland.ac.nz> = 05/13/00=20 05:36AM >>>
"David P. Kemp" <dpkemp@missi.ncsc.mil>=20 writes:

(Phew, back to technical discussions at=20 last)...

>Aren't you leaving out both a block and an assumption = in the=20 HTTP path?
>
>The assumptions are that the DSA not only is = based on=20 an RDBMS but that the
>RDBMS interface is exposed to other=20 applications.  If these assumptions are
>true, the paths would = be=20 more like:
>
>  client -> LDAP client -> LDAP = server=20 ---------\
>         &nb= sp;            =             &nb= sp;            =  =20 \
>           =             &nb= sp;            =             &nb= sp;=20 RDBMS
>          &n= bsp;            = ;            &n= bsp;            = ;=20 /
>  client -> HTTP GET -> Apache w/mod_perl &=20 DBI-/

Why would you need to run Apache?  The model I was = using=20 was:

   client -> socket read -> server stub = ->=20 RDBMS

Every RDBMS vendor on the planet either has or is making = their=20 database
web-aware (although for security purposes I'd prefer to stick = my own=20 stub in
front of it because I don't trust anyone to get things like = this=20 right :-).
The interface is incredibly trivial, using a speed-optimised= =20 database like
MySQL (which doesn't have a "lightweight" client like, = say,=20 Oracle), the
server stub isn't more than a page or two of code (bind = to a=20 socket, read
requests, drop them into a line of SQL, then call = mysql_query()=20 and
mysql_use_result()/fetch_row() and send the result back to the=20 caller.  I'm
sure I could crank it out in a hour or so (although = MySQL=20 does have web glue
built in if you want to go that way and use the = native=20 capabilities).

Total extra overhead in the client (assuming it = already=20 speaks SMTP, which
one can probably assume for a mail client): One = read and=20 one write call.

Total overhead in the server: An accept(), a read, = the=20 aforementioned RDBMS
glue code, and a write for the results.

You = can=20 even use the standard dictionary definition of lightweight to desribe=20
that.  It makes for a very nice, simple "gimme a cert" protocol = without=20 the
bloat and overhead of other=20 alternatives.

Peter.

--=_B5ED9D6D.395892DF-- From owner-ietf-smime Fri May 12 17:08:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA03367 for ietf-smime-bks; Fri, 12 May 2000 17:08:32 -0700 (PDT) Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03360 for ; Fri, 12 May 2000 17:08:31 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id RAA00055; Fri, 12 May 2000 17:12:17 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 17:13:08 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EAE3@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Bob Jueneman'" , pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org, dpkemp@missi.ncsc.mil Subject: RE: Border directories Date: Fri, 12 May 2000 17:13:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFBC4E.9C897BB0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BFBC4E.9C897BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bob said: >3. The much more significant point, unless I've overlooked a >"directoryCapabilities" attribute in the S/MIME spec somewhere , is that >both the originating and receiving application are completely clueless >as to where to find either the directory itself, or the http provider. >Once I use mental telephathy to figure out the DSN name of the server >where the user chose to publish his certificates(s), then I can start rummaging >around though either LDAP or HTTP, trying to guess the schema, and which >index to use to locate that user's certificate. >Those are the points we ought to be focussing on, IMHO. Well this was actually my main point. I have been trying to persuade folk to take the SRV record seriously and use it for this purpose for two years... So what is stopping the email client application vendors? Phill ------=_NextPart_000_0000_01BFBC4E.9C897BB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMzAwMTQwMFowIwYJKoZI hvcNAQkEMRYEFOhArRGvX7ebQMtg7aPUvMBwDl4nMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAOZJk6KJzUa3ua3opcGoNuYNvI+0dAo7wJiW4PJLmyLIhUO58C8Pf/nl9XR1Kw4JN ZLd9kwHuVBpiLelFZ4xgVRThAUz6yHvMC5vpzDMEq0WEgR3n5f61wdlJ6uUoOkIZV4mMkPArv2B0 bjLnURfzyKtvuMVHQz38FlEehoG8qt0AAAAAAAA= ------=_NextPart_000_0000_01BFBC4E.9C897BB0-- From owner-ietf-smime Fri May 12 22:00:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA04735 for ietf-smime-bks; Fri, 12 May 2000 22:00:48 -0700 (PDT) Received: from mauve.innosoft.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA04729 for ; Fri, 12 May 2000 22:00:47 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JPBSY5JR8G0000F7@mauve.mrochek.com> for ietf-smime@imc.org; Fri, 12 May 2000 22:06:28 -0800 (PST) Date: Fri, 12 May 2000 21:59:56 -0800 (PST) Subject: RE: Border directories In-reply-to: "Your message dated Fri, 12 May 2000 17:13:01 -0700" <2F3EC696EAEED311BB2D009027C3F4F408EAE3@vhqpostal.verisign.com> To: Philip Hallam-Baker Cc: "'Bob Jueneman'" , pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org, dpkemp@missi.ncsc.mil Message-id: <01JPBTO8NQFI0000F7@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well this was actually my main point. I have been trying to persuade folk > to take the SRV record seriously and use it for this purpose for two > years... > So what is stopping the email client application vendors? The lack of any specification explaining how SRV could be used by email clients might have something to do with it... And in the case of SMTP in particular, the existance of a widely deployed viable alternative (MX records) also plays a part. The SRV record specification is quite clear: Actual use of SRV records for specific protocols is beyond its scope. For that you need a SRV profile/applicability statement. If you see a useful application for SRV records in the email space (or any other space for that matter) what's needed is a document describing that usage, and I encourage you to write it out. This is what will persuade people to use SRV records. Ned From owner-ietf-smime Mon May 15 00:15:52 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA13343 for ietf-smime-bks; Mon, 15 May 2000 00:15:52 -0700 (PDT) Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13339 for ; Mon, 15 May 2000 00:15:47 -0700 (PDT) Received: from intouch1.software-aus.com.au (tforcep1.tforce.com.au [203.61.131.1]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with SMTP id RAA09329 for ; Mon, 15 May 2000 17:22:05 +1000 (EST) Message-Id: <4.1.20000515172733.009c5100@mail.ozemail.com.au> X-Sender: aferguso@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 May 2000 17:27:49 +1000 To: ietf-smime@mail.imc.org From: Andrew Ferguson Subject: S/MIME v3 plus ESS Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6357582==_.ALT" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_6357582==_.ALT Content-Type: text/plain; charset="us-ascii" Can any one tell me if they know of in production versions of S/MIMEv3 plus ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 2000) Thanks Andrew Ferguson --- Software Agencies Australia Pty Ltd (SAA) ACN 078 025 813 1 Huntingdale Road Burwood 3125 Victoria Australia Tel: +61-3-9831-6666 Fax: +61-3-9831-6624 Mob: +61-41-222-3940 Email: sales@software-aus.com.au URL: www.software-aus.com.au Offices in: Melbourne and Singapore (Software Agencies Asia). Resellers in: Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington, Auckland, Taipei and Kuala Lumpur. Your business integration partner for Internet Commerce, Messaging , Directories and Public Key Infrastructure security - give us a call we would love to help you with Internet Commerce. ---- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the intended recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test this Email before loading it onto any computer. Software Agencies Australia make every effort to ensure that no viruses are attached to this email however no warranty is given by Software Agencies Australia that this Email is free from computer viruses or any other defect or error. Software Agencies Australia is not liable for any loss or damage incurred by any person loading this Email or if liable Software Agencies Australia's obligation will be limited to retransmitting this email to the intended recipient. --=====================_6357582==_.ALT Content-Type: text/html; charset="us-ascii"
Can any one tell me if they know of in production versions of S/MIMEv3 plus ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 2000)

Thanks
Andrew Ferguson
---
Software Agencies Australia Pty Ltd (SAA)
ACN 078 025 813
1 Huntingdale Road
Burwood
3125 Victoria
Australia

Tel: +61-3-9831-6666
Fax: +61-3-9831-6624
Mob: +61-41-222-3940
Email: sales@software-aus.com.au
URL: www.software-aus.com.au
Offices in: Melbourne and Singapore (Software Agencies Asia).
Resellers in: Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington, Auckland, Taipei and Kuala Lumpur.

Your business integration partner for Internet Commerce, Messaging , Directories and Public Key Infrastructure security - give us a call we would love to help you with Internet Commerce.
----
The Information contained in this E-Mail and any subsequent  correspondence is private and is intended solely for the intended recipient(s).  For those other than the intended recipient any
disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test this Email before loading it onto any computer. Software Agencies Australia make every effort to ensure that no viruses are attached to this email however no warranty is given by Software Agencies Australia that this Email is free from computer viruses or any other defect or error. Software Agencies Australia is not liable for any loss or damage incurred by any person loading this Email or if liable Software Agencies Australia's obligation will be limited to retransmitting this email to the intended recipient.

--=====================_6357582==_.ALT-- From owner-ietf-smime Mon May 15 01:46:29 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA14951 for ietf-smime-bks; Mon, 15 May 2000 01:46:29 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA14947 for ; Mon, 15 May 2000 01:46:28 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 May 2000 01:51:33 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 15 May 2000 01:51:08 -0700 Message-ID: From: Jeff Tozzi To: "'Andrew Ferguson'" Cc: ietf-smime@mail.imc.org Subject: RE: S/MIME v3 plus ESS Date: Mon, 15 May 2000 01:52:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBE4A.E128AD60" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBE4A.E128AD60 Content-Type: text/plain; charset="ISO-8859-1" Andrew, Microsoft has an in-production version of S/MIME v3 ESS with their release of Outlook 2000 SR1 (released March 2000). Jeff Jeff Tozzi Program Manager Microsoft 425-705-8060 jtozzi@microsoft.com -----Original Message----- From: Andrew Ferguson [mailto:Andrew.Ferguson@software-aus.com.au] Sent: Monday, May 15, 2000 12:28 AM To: ietf-smime@mail.imc.org Subject: S/MIME v3 plus ESS Can any one tell me if they know of in production versions of S/MIMEv3 plus ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 2000) Thanks Andrew Ferguson --- Software Agencies Australia Pty Ltd (SAA) ACN 078 025 813 1 Huntingdale Road Burwood 3125 Victoria Australia Tel: +61-3-9831-6666 Fax: +61-3-9831-6624 Mob: +61-41-222-3940 Email: sales@software-aus.com.au URL: www.software-aus.com.au Offices in: Melbourne and Singapore (Software Agencies Asia). Resellers in: Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington, Auckland, Taipei and Kuala Lumpur. Your business integration partner for Internet Commerce, Messaging , Directories and Public Key Infrastructure security - give us a call we would love to help you with Internet Commerce. ---- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the intended recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test this Email before loading it onto any computer. Software Agencies Australia make every effort to ensure that no viruses are attached to this email however no warranty is given by Software Agencies Australia that this Email is free from computer viruses or any other defect or error. Software Agencies Australia is not liable for any loss or damage incurred by any person loading this Email or if liable Software Agencies Australia's obligation will be limited to retransmitting this email to the intended recipient. ------_=_NextPart_001_01BFBE4A.E128AD60 Content-Type: text/html; charset="ISO-8859-1"
Andrew,
 
Microsoft has an in-production version of S/MIME v3 ESS with their release of Outlook 2000 SR1 (released March 2000).
 
Jeff
 
Jeff Tozzi
Program Manager
Microsoft
425-705-8060
 

 -----Original Message-----
From: Andrew Ferguson [mailto:Andrew.Ferguson@software-aus.com.au]
Sent: Monday, May 15, 2000 12:28 AM
To: ietf-smime@mail.imc.org
Subject: S/MIME v3 plus ESS

Can any one tell me if they know of in production versions of S/MIMEv3 plus ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 2000)

Thanks
Andrew Ferguson
---
Software Agencies Australia Pty Ltd (SAA)
ACN 078 025 813
1 Huntingdale Road
Burwood
3125 Victoria
Australia

Tel: +61-3-9831-6666
Fax: +61-3-9831-6624
Mob: +61-41-222-3940
Email: sales@software-aus.com.au
URL: www.software-aus.com.au
Offices in: Melbourne and Singapore (Software Agencies Asia).
Resellers in: Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington, Auckland, Taipei and Kuala Lumpur.

Your business integration partner for Internet Commerce, Messaging , Directories and Public Key Infrastructure security - give us a call we would love to help you with Internet Commerce.
----
The Information contained in this E-Mail and any subsequent  correspondence is private and is intended solely for the intended recipient(s).  For those other than the intended recipient any
disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test this Email before loading it onto any computer. Software Agencies Australia make every effort to ensure that no viruses are attached to this email however no warranty is given by Software Agencies Australia that this Email is free from computer viruses or any other defect or error. Software Agencies Australia is not liable for any loss or damage incurred by any person loading this Email or if liable Software Agencies Australia's obligation will be limited to retransmitting this email to the intended recipient.

------_=_NextPart_001_01BFBE4A.E128AD60-- From owner-ietf-smime Mon May 15 06:23:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA21349 for ietf-smime-bks; Mon, 15 May 2000 06:23:30 -0700 (PDT) Received: from mail.bsb.zaz.com.br (mail.bsb.nutecnet.com.br [200.252.253.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21341 for ; Mon, 15 May 2000 06:23:25 -0700 (PDT) Received: from default (dl5014-bsb.bsb.nutecnet.com.br [200.252.15.14]) by mail.bsb.zaz.com.br (8.9.3/8.9.3) with SMTP id KAA11957 for ; Mon, 15 May 2000 10:32:15 -0300 Message-ID: <000c01bfbe59$154d0880$0d01a8c0@default> From: "Wellington Alencar" To: Subject: S/MIME Date: Mon, 15 May 2000 10:33:58 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BFBE59.13BBBA20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01BFBE59.13BBBA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I=B4m doing a homework about S/MIME, but I have problems...Can you help = me ? I need a chart about S/MIME.Do you Know where Can I find ? Thank=B4s Wellington Brazil ------=_NextPart_000_0009_01BFBE59.13BBBA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I=B4m doing a homework about S/MIME, but I have = problems...Can=20 you help me ?
I need a chart about S/MIME.Do you Know where Can I = find=20 ?
 
Thank=B4s
 
Wellington
Brazil
------=_NextPart_000_0009_01BFBE59.13BBBA20-- From owner-ietf-smime Mon May 15 08:10:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23264 for ietf-smime-bks; Mon, 15 May 2000 08:10:03 -0700 (PDT) Received: from hen.scotland.net (phys-hen2.scotland.net [194.247.65.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23254 for ; Mon, 15 May 2000 08:10:00 -0700 (PDT) Received: from [148.176.234.79] (helo=jrwork) by hen.scotland.net with smtp (Exim 2.12 #2) id 12rMXm-0004Lt-00; Mon, 15 May 2000 16:12:31 +0100 Message-ID: <002c01bfbe7f$4031e900$0400000a@jrwork> From: "John Ross" To: "Russ Housley" Cc: "s/mime list" Subject: Fw: ETSI ES 201 733 Electronic Signature Formats Date: Mon, 15 May 2000 16:07:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ & all The ETSI document on Electronic Signature Formats and Signature Policies is now an approved ETSI document, see the ETSI El Sign Website http://www.etsi.org/sec/el-sign.htm The ASN.1 has been split into four modules, two for Electronic Signature Formats and two for Electronic Signature Policies. I intend to divide the current IETF draft text along the same lines and have another version of the IETF document ready in a couple of weeks. Regards John Ross -----Original Message----- From: Harri Rasilainen To: SEC_ESI@LIST.ETSI.FR Date: 15 May 2000 08:56 Subject: ETSI ES 201 733 Electronic Signature Formats >Dear all, >The ETSI ES 201 733 Electronic Signature Formats standard has been approved >and >published. >To ensure there are no copyright issues in the final published version, >where text from RFC was previously duplicated in draft ETSI ES 201 733, such >text has >now been incorporated by reference. >The standard is available from the ETSI web site: >http://webapp.etsi.org/pda/ > >and the ETSI El Sign Website >http://www.etsi.org/sec/el-sign.htm > > >Best regards, >Harri Rasilainen >ETSI Technical Officer - SEC, TETRA and SAGE >Tel: +33 6 87 69 12 51 > >Technical news from ETSI: > http://www.etsi.org/tbnews/ta_news.htm > From owner-ietf-smime Wed May 17 21:35:05 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA13378 for ietf-smime-bks; Wed, 17 May 2000 21:35:05 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13371 for ; Wed, 17 May 2000 21:35:03 -0700 (PDT) Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id VAA15900 for ; Wed, 17 May 2000 21:41:41 -0700 (PDT) From: "Jim Schaad" Reply-to: jimsch@nwlink.com To: ietf-smime@imc.org Date: Wed, 17 May 2000 21:41:41 +0800 Subject: Cert Dist Changes Message-id: <39237485.10d23.0@nwlink.com> X-User-Info: 131.107.3.84 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since I have been out of touch and have not be able to respond well to comments on this draft, I will attempt to summerize the comments in this message as well as the action that I have taken about them. A new draft is on the way to the editors at the same time as this message went out. 1. LDAP was not understandable as writen. I have changed to using the LDAP v2 rather than LDAP v3 descriptions so that they look more like what people understand. It is perfectly possible that I did not understand what the v3 docs were trying to do and so got the v3 schema completely wrong. 2. May omit user's certificate if publishing to LDAP. This is the one with the most traffic. The arguments that I have found are: a) The document should be modified so that the text states that the certificate MUST NOT appear in an LDAP entry. - I don't like the text MUST NOT. It is quite possible that when I prepare a CertDist object for publication I don't know where it will appear or it may appear in multiple places. Putting the MUST NOT text in says that I need to either be able to manipulate the object at publication time or potentially start creating multiple objects. Note this goes in the opposite direction as well, something move the attribute from LDAP to http get would need to insert the certificate. b) The document does not say what do to in the absence of the property. - I don't believe the document needs to discuss other ways of obtaining certificates. More specifically the text to deal with this is very LDAP specific and I don't want to tie the document any closer to LDAP than necessary. c) Need to look at two attributes to find the certificates. - Given the relative time involved, I think that most applications are going to pull down multiple attributes at once in any event. The time involved in pulling down extra bytes vs the time involved in establishing and re-querying to get the correct result seems to me to indicate that all possible attributes should be pulled at once if you even suspect that you might need this. From my days at Microsoft one of the worse things to do for performance was to ask anything new of the directory or message store. The cost of doing one extra RPC was just a killer. d) Does not work with existing code bases as currently written. - We are writing standards not documenting existing code. This implies that we need to do things right and not just document things that are wrong but already in use. RESULT: I have pulled the MAY text from the document for the following reasons: 1. The reason it was put in was to deal with size issues in the directory. After looking at this, the savings from not having the end-entity certificate duplicated in a single directory entry, but still having the entire chain of certificates above it duplicated in every end-entity record just seems a bit extreme. It would be possible for a server which really cared about space to do this operation itself, and do the space savings on chaining certificates as well. 2. The difficulty of moving an item from an LDAP to a non-LDAP location where the certificate is inserted or removed as appropriate seems to be a killer type problem. If the searching abilities are not present, then we need to look at how to add them to the document, but I will need help from some real LDAP people on how to do this. Please provide me with the necessary set of text and references so that I can understand what you have suggested. jim http://www.nwlink.com From owner-ietf-smime Thu May 18 07:51:10 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA19492 for ietf-smime-bks; Thu, 18 May 2000 07:51:10 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19488 for ; Thu, 18 May 2000 07:51:09 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA10259; Thu, 18 May 2000 10:52:55 -0400 (EDT) Message-Id: <200005181452.KAA10255@roadblock.missi.ncsc.mil> Date: Thu, 18 May 2000 10:54:13 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Cert Dist Changes To: ietf-smime@imc.org, jimsch@nwlink.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: w1MWkw8LYbFIlVAPH9/bVQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, If the new draft specifies that the userSmimeCertificate LDAP attribute contains either user certificates or CA certificates, it is in conflict with the PKIX directory schema. *No* certificates should appear in this attribute, *All* certificates should be populated in the standard PKIX locations: userCertificate and caCertificate. Size considerations are a very minor concern to me, although the size difference between "smimeCapabilities only" and "smimeCapabilities + full cert path" is significant. The major concern is the duplication of data, and the corresponding likelihood that the data will get out of sync. If you believe that it is too difficult to fetch certificates from the directory when formatting a CertDist object for http retrieval, or alternatively stripping the cert path out when populating the CertDist object as a directory attribute, then you certainly must not be inclined to check CertDist objects which contain certificates for consistency with the certs already in the userCertificate and caCertificate attributes of the directory. SMIME LDAP attribute definitions must be compatible with and non-duplicative of PKIX LDAP attribute definitions. Until that is the case with Certdist, I will continue to oppose its approval as an RFC. Regards, Dave > From: "Jim Schaad" > To: ietf-smime@imc.org > Date: Wed, 17 May 2000 21:41:41 +0800 > Subject: Cert Dist Changes > X-User-Info: 131.107.3.84 > > Since I have been out of touch and have not be able to respond well to comments > on this draft, I will attempt to summerize the comments in this message as well > as the action that I have taken about them. A new draft is on the way to the > editors at the same time as this message went out. > > 1. LDAP was not understandable as writen. I have changed to using the LDAP > v2 rather than LDAP v3 descriptions so that they look more like what people > understand. It is perfectly possible that I did not understand what the v3 > docs were trying to do and so got the v3 schema completely wrong. > > 2. May omit user's certificate if publishing to LDAP. This is the one with > the most traffic. The arguments that I have found are: > > a) The document should be modified so that the text states that the certificate > MUST NOT appear in an LDAP entry. > > - I don't like the text MUST NOT. It is quite possible that when I prepare > a CertDist object for publication I don't know where it will appear or it may > appear in multiple places. Putting the MUST NOT text in says that I need to > either be able to manipulate the object at publication time or potentially start > creating multiple objects. Note this goes in the opposite direction as well, > something move the attribute from LDAP to http get would need to insert the > certificate. > > b) The document does not say what do to in the absence of the property. > > - I don't believe the document needs to discuss other ways of obtaining certificates. > More specifically the text to deal with this is very LDAP specific and I don't > want to tie the document any closer to LDAP than necessary. > > c) Need to look at two attributes to find the certificates. > > - Given the relative time involved, I think that most applications are going > to pull down multiple attributes at once in any event. The time involved in > pulling down extra bytes vs the time involved in establishing and re-querying > to get the correct result seems to me to indicate that all possible attributes > should be pulled at once if you even suspect that you might need this. From > my days at Microsoft one of the worse things to do for performance was to ask > anything new of the directory or message store. The cost of doing one extra > RPC was just a killer. > > d) Does not work with existing code bases as currently written. > > - We are writing standards not documenting existing code. This implies that > we need to do things right and not just document things that are wrong but already > in use. > > > RESULT: > > I have pulled the MAY text from the document for the following reasons: > 1. The reason it was put in was to deal with size issues in the directory. > After looking at this, the savings from not having the end-entity certificate > duplicated in a single directory entry, but still having the entire chain of > certificates above it duplicated in every end-entity record just seems a bit > extreme. It would be possible for a server which really cared about space to > do this operation itself, and do the space savings on chaining certificates > as well. > > 2. The difficulty of moving an item from an LDAP to a non-LDAP location where > the certificate is inserted or removed as appropriate seems to be a killer type > problem. > > If the searching abilities are not present, then we need to look at how to add > them to the document, but I will need help from some real LDAP people on how > to do this. Please provide me with the necessary set of text and references > so that I can understand what you have suggested. > > jim > http://www.nwlink.com > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** From owner-ietf-smime Fri May 19 03:45:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01789 for ietf-smime-bks; Fri, 19 May 2000 03:45:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01783 for ; Fri, 19 May 2000 03:45:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02537; Fri, 19 May 2000 06:52:00 -0400 (EDT) Message-Id: <200005191052.GAA02537@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-certdist-05.txt Date: Fri, 19 May 2000 06:51:59 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Certificate Distribution Specification Author(s) : J. Schaad Filename : draft-ietf-smime-certdist-05.txt Pages : 20 Date : 18-May-00 Current methods of publishing certificates in directory services are restricted to just certificates. This document provides a method of publishing certificates with secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-certdist-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-certdist-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-certdist-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000518091821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-certdist-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-certdist-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000518091821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Fri May 19 21:17:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA17870 for ietf-smime-bks; Fri, 19 May 2000 21:17:21 -0700 (PDT) Received: from platon.becomsys.de (root@platon.becomsys.de [194.162.52.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17866 for ; Fri, 19 May 2000 21:17:20 -0700 (PDT) Received: from host (1Cust24.tnt2.providence.ri.da.uu.net [63.21.182.24]) by platon.becomsys.de (8.8.8/8.8.8) with ESMTP id GAA27685; Sat, 20 May 2000 06:12:39 +0200 Message-Id: <200005200412.GAA27685@platon.becomsys.de> From: "Karl Serny" Subject: You Can Win... # 37B To: half39f@platon.becomsys.de X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Fri, 19 May 2000 23:02:17 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA17867 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you interested in increasing your odds in winning a lottery? To find out how, reply to: mailto:aamk@crosswinds.net?subject=How_to_win We will only respond if all of the information below is completed. Thanks for your time. Name: _________________________________________ Email Address: __________________________________ Address __________________________________________ City ________________________ ST _____ ZIP __________ Phone (_______) ______________________Best time to call. ***************************************************************** This message is sent in compliance of the new email bill section 301. PerSection 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. ================================================================= If you wish to be removed from future mailings, please Reply to:mailto:yykpm@usa.net?subject=remove From owner-ietf-smime Sun May 21 17:44:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06760 for ietf-smime-bks; Sun, 21 May 2000 17:44:50 -0700 (PDT) Received: from interser.www2.opegieka.com.pl (interser.opegieka.com.pl [195.116.116.121] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06756 for ; Sun, 21 May 2000 17:44:44 -0700 (PDT) Message-Id: <200005220044.RAA06756@ns.secondary.com> Received: from host (1Cust17.tnt1.providence.ri.da.uu.net [63.21.181.17]) by interser.www2.opegieka.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KKLWWV2Q; Mon, 22 May 2000 03:00:31 +0200 From: "Wendy Steiner" Subject: A Must See #2199 To: op29s X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 21 May 2000 18:18:47 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA06757 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Start your own 1-900 business or Adult Web Site Business! People are making $$$ week, after week in the 1-900 business. We'll teach you all of our incredible secrets that will take your new exciting business to a whole new level! It's The Simplest and Most Exciting Business You Could Ever Start! *You'll use our "state" of the art equipment! *You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls! *You'll use our incredible Date Line program(s)! No chargebacks! Quick payouts! No expertise needed! Complete programs start at only $99 (no additional charges) The only thing you'll have to do is advertise! This is an excellent turnkey business. We also have excellent turnkey programs if you want to own your own "top" of the line adult web site. ACT NOW!!! For a free color brochure: reply to: mailto:sandk@populus.net?subject=brochure With the following information: Name:_________________ Address:_________________ City/State/Zip:_________________ email address:_________________ Telephone:_________________ (optional) /////////////////////////////////////////////////// To be removed permanantly from this list reply to: mailto:yyk@fsmail.net?subject=remove /////////////////////////////////////////////////// From owner-ietf-smime Tue May 23 03:28:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11334 for ietf-smime-bks; Tue, 23 May 2000 03:28:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11330 for ; Tue, 23 May 2000 03:28:52 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29393; Tue, 23 May 2000 06:35:56 -0400 (EDT) Message-Id: <200005231035.GAA29393@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-04.txt Date: Tue, 23 May 2000 06:35:56 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-04.txt Pages : 6 Date : 22-May-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000522131539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000522131539.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue May 23 07:22:37 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15415 for ietf-smime-bks; Tue, 23 May 2000 07:22:37 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15411 for ; Tue, 23 May 2000 07:22:36 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA16812 for ; Tue, 23 May 2000 10:24:13 -0400 (EDT) Message-Id: <200005231424.KAA16808@roadblock.missi.ncsc.mil> Date: Tue, 23 May 2000 10:26:31 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Border directories To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +Os8NFXnHjLZTpqzx2st+A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I acknowledge that one can shift complexity around in any system, and that by both eliminating options and shifting processing to a server, one can make a small client that does just one thing, and even succeeds in doing it some of the time. But to eliminate the ESP that Bob referred to (given an email address, how does the client devine which RDBMS to query for a cert?) one needs a client that talks not only HTTP or SMTP but also BIND. That's another several lines to your 10 line client. It also assumes that everyone: 1) stands up an HTTP-accessible RDBMS to serve certificates, including populating the RDBMS when the directory backend is only usable through a directory interface, and 2) populates SRV records in the DNS to point to the HTTP/RDBMS server. The alternative, of course, is to talk to the directory directly. I couldn't accept the assertion that a "Lightweight" client is 1MB, so last night I did an experiment of pruning out some unused code from an OpenLDAP client. The result is a 54KB executable that can fetch any LDAP attribute (not just certificates) using any search criteria (not just email address), including wildcards. Code mailed on request. 54 KB is within the realm of what could be called Lightweight. With a few more hours of surgery (which I have no intention of pursuing) it might get down to half that, or less if the client already includes a BER library (which it will if it actually uses the certificate for anything :-). The best part is that LDAP uses the infrastructure which is already in place, rather than requiring everyone to stand up Something Else. Dave > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > Date: Sat, 13 May 2000 05:36:15 (NZST) > > ... > > Every RDBMS vendor on the planet either has or is making their database > web-aware (although for security purposes I'd prefer to stick my own stub in > front of it because I don't trust anyone to get things like this right :-). > The interface is incredibly trivial, using a speed-optimised database like > MySQL (which doesn't have a "lightweight" client like, say, Oracle), the > server stub isn't more than a page or two of code (bind to a socket, read > requests, drop them into a line of SQL, then call mysql_query() and > mysql_use_result()/fetch_row() and send the result back to the caller. I'm > sure I could crank it out in a hour or so (although MySQL does have web glue > built in if you want to go that way and use the native capabilities). > > Total extra overhead in the client (assuming it already speaks SMTP, which > one can probably assume for a mail client): One read and one write call. > > Total overhead in the server: An accept(), a read, the aforementioned RDBMS > glue code, and a write for the results. > > You can even use the standard dictionary definition of lightweight to desribe > that. It makes for a very nice, simple "gimme a cert" protocol without the > bloat and overhead of other alternatives. > > Peter. From owner-ietf-smime Thu May 25 03:48:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03166 for ietf-smime-bks; Thu, 25 May 2000 03:48:30 -0700 (PDT) Received: from bart.callnet0800.com (bart.callnet0800.com [212.67.128.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03161 for ; Thu, 25 May 2000 03:48:28 -0700 (PDT) Received: from smtp.callnetuk.com [212.67.128.5] by bart.callnet0800.com with ESMTP (SMTPD32-5.05) id A69431F000EE; Thu, 25 May 2000 11:55:25 +0100 Received: from develera [212.67.129.83] by smtp.callnetuk.com (SMTPD32-5.05) id A65610B901FA; Thu, 25 May 2000 11:54:14 +0100 From: "Frank O'Dwyer" To: "Bob Jueneman" , , , Subject: RE: Border directories Date: Thu, 25 May 2000 11:54:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Disposition-Notification-To: "Frank O'Dwyer" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob Jueneman wrote: >3. The much more significant point, unless I've overlooked a >"directoryCapabilities" attribute in the S/MIME spec somewhere , is that >both the originating and receiving application are completely clueless >as to where to find either the directory itself, or the http provider. I had been wondering how S/MIME addressed mapping of an email address to a directory server address. From the sound of this thread, I guess it doesn't. So how are people doing this in practice? Is everyone setting up an LDAP directory, then ignoring it and exchanging certificates by email? Or just hardwiring a few LDAP servers into client configs? Cheers, Frank O'Dwyer fod@brd.ie --- Outgoing mail has been scanned for viruses. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.145 / Virus Database: 69 - Release Date: 5/4/00 From owner-ietf-smime Thu May 25 08:37:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13387 for ietf-smime-bks; Thu, 25 May 2000 08:37:17 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13382 for ; Thu, 25 May 2000 08:37:13 -0700 (PDT) Received: by balinese.baltimore.ie; id QAA15783; Thu, 25 May 2000 16:44:24 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015713; Thu, 25 May 00 16:43:25 +0100 Received: from irlbdc.irl.emea (irlbdc.baltimore.ie [192.168.20.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA32503 for ; Thu, 25 May 2000 16:43:25 +0100 Received: by irlbdc.cdsemea.baltimore.com with Internet Mail Service (5.5.2448.0) id ; Thu, 25 May 2000 16:44:13 +0100 Message-ID: <3B46C515DDE2D311A70C005004AFCB7012196A@emeairl2.cdsemea.baltimore.com> From: William Whyte To: ietf-smime@imc.org Subject: draft-ietf-smime-idea-04.txt: parameters question Date: Thu, 25 May 2000 16:44:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IDEA in CMS draft specifies the parameters as follows: IDEA-CBCPar ::= SEQUENCE { IV OCTET STRING OPTIONAL -- exactly 8 octets } Is there a good reason for the SEQUENCE wrapping? We already have a CBCParameter structure defined in RFC 2630, and it seems a shame to be inventing a slightly-differently-shaped wheel. Cheers, William From owner-ietf-smime Thu May 25 11:35:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17280 for ietf-smime-bks; Thu, 25 May 2000 11:35:27 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17276 for ; Thu, 25 May 2000 11:35:26 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA28258 for ; Thu, 25 May 2000 14:36:58 -0400 (EDT) Message-Id: <200005251836.OAA28254@roadblock.missi.ncsc.mil> Date: Thu, 25 May 2000 14:39:25 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Border directories To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oz/RB+nFzxs/srk0673F5g== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wouldn't say we do hardwiring; it's more like seeing a URL on TV and typing it into a browser :-). When users register for a DoD certificate, they get an instruction sheet for adding the DoD root and finding the directory. Coordination from the DoD to other directories is not complete, but people are working on it. See http://www.fts.gsa.gov/html/fedware/Govt_OnlineDirectories.html. Dave > From: "Frank O'Dwyer" > > Bob Jueneman wrote: > >3. The much more significant point, unless I've overlooked a > >"directoryCapabilities" attribute in the S/MIME spec somewhere , is that > >both the originating and receiving application are completely clueless > >as to where to find either the directory itself, or the http provider. > > I had been wondering how S/MIME addressed mapping of an email address to a > directory server address. From the sound of this thread, I guess it doesn't. > So how are people doing this in practice? Is everyone setting up an LDAP > directory, then ignoring it and exchanging certificates by email? Or just > hardwiring a few LDAP servers into client configs? > > Cheers, > Frank O'Dwyer > fod@brd.ie From owner-ietf-smime Fri May 26 09:42:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09587 for ietf-smime-bks; Fri, 26 May 2000 09:42:56 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09583 for ; Fri, 26 May 2000 09:42:55 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA29115; Fri, 26 May 2000 09:49:39 -0700 (PDT) Message-Id: <4.2.0.58.20000526121619.00959580@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 12:23:33 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: WG LAST CALL: draft-ietf-smime-idea-04.txt Cc: jis@mit.edu, MLeech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IDEA algorithm document, draft-ietf-smime-idea-04.txt, is ready for S/MIME WG Last Call. This document is slated to become an informational RFC. Last Call will end on 12 June 2000. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-04.txt Pages : 6 Date : 22-May-00 Please note that an statement regarding IDEA and patents has been posted at http://www.ietf.org/ipr.html. Happy reading, Russ From owner-ietf-smime Fri May 26 11:39:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11596 for ietf-smime-bks; Fri, 26 May 2000 11:39:36 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11592 for ; Fri, 26 May 2000 11:39:35 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA01022; Fri, 26 May 2000 11:46:17 -0700 (PDT) Message-Id: <4.2.0.58.20000526142332.00aad290@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 14:33:20 -0400 To: William Whyte From: Russ Housley Subject: Re: draft-ietf-smime-idea-04.txt: parameters question Cc: ietf-smime@imc.org In-Reply-To: <3B46C515DDE2D311A70C005004AFCB7012196A@emeairl2.cdsemea.ba ltimore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree. This was probably follows SKIPJACK. In that case, they are including the SEQUENCE wrapper for compatibility with another environment. Here, I am unaware of any compatibility requirement. SKIPJACK uses: Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING } I suggest that IDEA should use: IDEA-CBC-IV ::= OCTET STRING -- must be 8 octets Russ P.S. Authors, please consider this to be a Last Call comment. At 04:44 PM 05/25/2000 +0100, William Whyte wrote: >The IDEA in CMS draft specifies the parameters as follows: > > IDEA-CBCPar ::= SEQUENCE { > IV OCTET STRING OPTIONAL -- exactly 8 octets } > >Is there a good reason for the SEQUENCE wrapping? We already >have a CBCParameter structure defined in RFC 2630, and it >seems a shame to be inventing a slightly-differently-shaped >wheel. > >Cheers, > >William From owner-ietf-smime Tue May 30 03:27:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA00635 for ietf-smime-bks; Tue, 30 May 2000 03:27:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00630 for ; Tue, 30 May 2000 03:27:15 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22839; Tue, 30 May 2000 06:34:53 -0400 (EDT) Message-Id: <200005301034.GAA22839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-domsec-05.txt Date: Tue, 30 May 2000 06:34:53 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Domain Security Services using S/MIME Author(s) : T. Dean, W. Ottaway Filename : draft-ietf-smime-domsec-05.txt Pages : 8 Date : 26-May-00 This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely, for example when two domains use incompatible messaging technologies such as X.400 and SMTP/MIME, or when a single domain wishes to communicate securely with one of its members residing on an untrusted domain. The scenarios covered by this document are domain to domain, individual to domain and domain to individual communications. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-domsec-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-domsec-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000526105633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-domsec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-domsec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000526105633.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue May 30 05:28:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05026 for ietf-smime-bks; Tue, 30 May 2000 05:28:19 -0700 (PDT) Received: from bart.callnet0800.com (bart.callnet0800.com [212.67.128.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05019 for ; Tue, 30 May 2000 05:26:57 -0700 (PDT) Received: from smtp.callnetuk.com [212.67.128.5] by bart.callnet0800.com with ESMTP (SMTPD32-5.05) id A56DAD0011A; Tue, 30 May 2000 13:34:53 +0100 Received: from develera [212.67.132.137] by smtp.callnetuk.com (SMTPD32-5.05) id A54328D10242; Tue, 30 May 2000 13:34:11 +0100 From: "Frank O'Dwyer" To: "David P. Kemp" , Subject: RE: Border directories Date: Tue, 30 May 2000 13:34:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <200005251836.OAA28254@roadblock.missi.ncsc.mil> Importance: Normal Disposition-Notification-To: "Frank O'Dwyer" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I wouldn't say we do hardwiring; it's more like seeing a URL on TV and > typing it into a browser :-). When users register for a DoD > certificate, they get an instruction sheet for adding the DoD root and > finding the directory. That does seem to be the only way to do it at present. However, it also sounds like it has severe scaling problems for users who need to work with many disjoint directories. Presumably if there is no mapping from email address to directory server, then it is necessary to look in them all. That has to be a big performance hit (for the LDAP servers concerned). It also unnecessarily leaks information about who is communicating with whom. Even a simple convention such as having clients attempt a lookup for user@company.com by connecting to ldap.company.com would go a long way to address that (even if it is a bit of a kludge). Cheers, Frank. > Coordination from the DoD to other directories is not complete, but > people are working on it. > See http://www.fts.gsa.gov/html/fedware/Govt_OnlineDirectories.html. > > Dave > > > > > From: "Frank O'Dwyer" > > > > Bob Jueneman wrote: > > >3. The much more significant point, unless I've overlooked a > > >"directoryCapabilities" attribute in the S/MIME spec > somewhere , is that > > >both the originating and receiving application are completely clueless > > >as to where to find either the directory itself, or the http provider. > > > > I had been wondering how S/MIME addressed mapping of an email > address to a > > directory server address. From the sound of this thread, I > guess it doesn't. > > So how are people doing this in practice? Is everyone setting up an LDAP > > directory, then ignoring it and exchanging certificates by > email? Or just > > hardwiring a few LDAP servers into client configs? > > > > Cheers, > > Frank O'Dwyer > > fod@brd.ie > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.145 / Virus Database: 69 - Release Date: 5/4/00 > --- Outgoing mail has been scanned for viruses. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.145 / Virus Database: 69 - Release Date: 5/4/00 From owner-ietf-smime Wed May 31 06:42:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07287 for ietf-smime-bks; Wed, 31 May 2000 06:42:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07283 for ; Wed, 31 May 2000 06:42:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09713; Wed, 31 May 2000 09:50:03 -0400 (EDT) Message-Id: <200005311350.JAA09713@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-smime@imc.org From: The IESG Subject: Document Action: Use of the KEA and SKIPJACK Algorithms in CMS to Informational Date: Wed, 31 May 2000 09:50:02 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Use of the KEA and SKIPJACK Algorithms in CMS' as a Informational. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. From owner-ietf-smime Wed May 31 23:03:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06497 for ietf-smime-bks; Wed, 31 May 2000 23:03:15 -0700 (PDT) Received: from vejlehs.vejlehs.dk (vejlehs.vejlehs.dk [194.182.192.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06493 for ; Wed, 31 May 2000 23:03:13 -0700 (PDT) Received: from host (ip57.providence11.ri.pub-ip.psi.net [38.26.242.57]) by vejlehs.vejlehs.dk (8.8.5/SCO5) with ESMTP id IAA15934; Thu, 1 Jun 2000 08:10:30 +0200 (CETDST) Message-Id: <200006010610.IAA15934@vejlehs.vejlehs.dk> From: "Rob Saky" Subject: FREE INFORMATION # DED To: join29d@vejlehs.vejlehs.dk X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Wed, 31 May 2000 21:25:21 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA06494 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! ******Act now and all App. & Processing fees waived***** call our (888) 363-7881 now! Our courteous customer care reps. are anxious to help you get your merchant account today. Merchant Status will help you increase sales by an incredible 50% to 400%. Stop losing valuable sales! With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining customer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs whom are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all app. and processing fees! (Other companies charge $200 to $500 to set up) In Business since 1992 Call us today @ 1 (888) 363-7881 and ask for extension FBK for free setup! **************************************************** If you have received this message in error, please remove at: mailto:qp88k@netscape.net?subject=remove **************************************************** From owner-ietf-smime Thu Jun 1 22:26:18 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA12631 for ietf-smime-bks; Thu, 1 Jun 2000 22:26:18 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12626 for ; Thu, 1 Jun 2000 22:26:17 -0700 (PDT) Received: from jimsch1t (ip32.du1.ptl.nwlink.com [209.20.137.32]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id WAA23706; Thu, 1 Jun 2000 22:34:03 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "David P. Kemp" , , Subject: RE: Cert Dist Changes Date: Thu, 1 Jun 2000 21:34:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <200005181452.KAA10255@roadblock.missi.ncsc.mil> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am a bit loss for words. Are you saying that data is to appear in one and only one location in the directory and not to be duplicated? If this is not the case then I don't see your problem although consistancy can be a problem depending on the different tools used to update the directory for different purposes. (A mail program publishing information vs an access control program (such as the Win2K directory might not keep/correctly update all fields.) There is nothing that does not let you put things into the userCertificate and caCertificate fields, however many programs only update the userCertificate field at present. The code that I wrote while at Microsoft would publish into both the userSMimeCertificate and userCertificate fields but ignored the caCertificate field as this exists only on CAs. This means that if a user publishes a certificate in a different directory (possibly unaccessable) directory, the client has no way of getting to CA certificates, thus for the general case caCertificates is unuseful. One part of me would be more that happy to deprecate the use of userCertificate given some of the problems assocated with its use (outlined in the draft), but I don't expect that to happen any time soon. What does it mean if some other application which does not understand or reference the userSmimeCertificate (having only implemented the PKIX docs) removes a certificate from userCertificates that is referenced by the userSmimeCertificate property. This leads to inconsistancies on the other-side of the fence if the certificates are not included. I don't think that you would ever be able to ensure consistancy unless the directory itself does so. jim -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Thursday, May 18, 2000 7:54 AM To: ietf-smime@imc.org; jimsch@nwlink.com Subject: Re: Cert Dist Changes Jim, If the new draft specifies that the userSmimeCertificate LDAP attribute contains either user certificates or CA certificates, it is in conflict with the PKIX directory schema. *No* certificates should appear in this attribute, *All* certificates should be populated in the standard PKIX locations: userCertificate and caCertificate. Size considerations are a very minor concern to me, although the size difference between "smimeCapabilities only" and "smimeCapabilities + full cert path" is significant. The major concern is the duplication of data, and the corresponding likelihood that the data will get out of sync. If you believe that it is too difficult to fetch certificates from the directory when formatting a CertDist object for http retrieval, or alternatively stripping the cert path out when populating the CertDist object as a directory attribute, then you certainly must not be inclined to check CertDist objects which contain certificates for consistency with the certs already in the userCertificate and caCertificate attributes of the directory. SMIME LDAP attribute definitions must be compatible with and non-duplicative of PKIX LDAP attribute definitions. Until that is the case with Certdist, I will continue to oppose its approval as an RFC. Regards, Dave > From: "Jim Schaad" > To: ietf-smime@imc.org > Date: Wed, 17 May 2000 21:41:41 +0800 > Subject: Cert Dist Changes > X-User-Info: 131.107.3.84 > > Since I have been out of touch and have not be able to respond well to comments > on this draft, I will attempt to summerize the comments in this message as well > as the action that I have taken about them. A new draft is on the way to the > editors at the same time as this message went out. > > 1. LDAP was not understandable as writen. I have changed to using the LDAP > v2 rather than LDAP v3 descriptions so that they look more like what people > understand. It is perfectly possible that I did not understand what the v3 > docs were trying to do and so got the v3 schema completely wrong. > > 2. May omit user's certificate if publishing to LDAP. This is the one with > the most traffic. The arguments that I have found are: > > a) The document should be modified so that the text states that the certificate > MUST NOT appear in an LDAP entry. > > - I don't like the text MUST NOT. It is quite possible that when I prepare > a CertDist object for publication I don't know where it will appear or it may > appear in multiple places. Putting the MUST NOT text in says that I need to > either be able to manipulate the object at publication time or potentially start > creating multiple objects. Note this goes in the opposite direction as well, > something move the attribute from LDAP to http get would need to insert the > certificate. > > b) The document does not say what do to in the absence of the property. > > - I don't believe the document needs to discuss other ways of obtaining certificates. > More specifically the text to deal with this is very LDAP specific and I don't > want to tie the document any closer to LDAP than necessary. > > c) Need to look at two attributes to find the certificates. > > - Given the relative time involved, I think that most applications are going > to pull down multiple attributes at once in any event. The time involved in > pulling down extra bytes vs the time involved in establishing and re-querying > to get the correct result seems to me to indicate that all possible attributes > should be pulled at once if you even suspect that you might need this. >From > my days at Microsoft one of the worse things to do for performance was to ask > anything new of the directory or message store. The cost of doing one extra > RPC was just a killer. > > d) Does not work with existing code bases as currently written. > > - We are writing standards not documenting existing code. This implies that > we need to do things right and not just document things that are wrong but already > in use. > > > RESULT: > > I have pulled the MAY text from the document for the following reasons: > 1. The reason it was put in was to deal with size issues in the directory. > After looking at this, the savings from not having the end-entity certificate > duplicated in a single directory entry, but still having the entire chain of > certificates above it duplicated in every end-entity record just seems a bit > extreme. It would be possible for a server which really cared about space to > do this operation itself, and do the space savings on chaining certificates > as well. > > 2. The difficulty of moving an item from an LDAP to a non-LDAP location where > the certificate is inserted or removed as appropriate seems to be a killer type > problem. > > If the searching abilities are not present, then we need to look at how to add > them to the document, but I will need help from some real LDAP people on how > to do this. Please provide me with the necessary set of text and references > so that I can understand what you have suggested. > > jim > http://www.nwlink.com > > > **************************************************************************** * > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > **************************************************************************** ** From owner-ietf-smime Fri Jun 2 07:46:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14834 for ietf-smime-bks; Fri, 2 Jun 2000 07:46:45 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14830 for ; Fri, 2 Jun 2000 07:46:43 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA07253 for ; Fri, 2 Jun 2000 10:48:01 -0400 (EDT) Message-Id: <200006021448.KAA07245@roadblock.missi.ncsc.mil> Date: Fri, 2 Jun 2000 10:52:16 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Cert Dist Changes To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dNoxtVldyNpXwrobEyO0rQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: "Jim Schaad" > To: "David P. Kemp" , , > Subject: RE: Cert Dist Changes > Date: Thu, 1 Jun 2000 21:34:34 -0700 > > I am a bit loss for words. Are you saying that data is to appear in one and > only one location in the directory and not to be duplicated? If this is not > the case then I don't see your problem although consistancy can be a problem > depending on the different tools used to update the directory for different > purposes. (A mail program publishing information vs an access control > program (such as the Win2K directory might not keep/correctly update all > fields.) > > There is nothing that does not let you put things into the userCertificate > and caCertificate fields, however many programs only update the > userCertificate field at present. The code that I wrote while at Microsoft > would publish into both the userSMimeCertificate and userCertificate fields > but ignored the caCertificate field as this exists only on CAs. This means > that if a user publishes a certificate in a different directory (possibly > unaccessable) directory, the client has no way of getting to CA > certificates, thus for the general case caCertificates is unuseful. Jim, That is precisely the situation (CA certificates not being accessible to all consuming applications) I think we should be trying to avoid. If you start with a directory environment where caCertificate is not useful, and you want to allow a particular application (S/MIME) to operate, you have two possible courses of action: 1) encourage directory administrators to make caCertificate useful, or 2) encourage directory administrators to populate an S/MIME-specific attribute to bypass the need for caCertificate. I believe that option 2 is harmful to the Internet environment. Once administrators have made the effort to populate a repository with certificates, the identical repository should be usable by S/MIME, SSL, IPsec, and other applications. Developing a stovepipe (single-purpose) solution is easier in the short run, but will cost us dearly later. Regards, Dave From owner-ietf-smime Fri Jun 2 11:35:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA23393 for ietf-smime-bks; Fri, 2 Jun 2000 11:35:07 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23388 for ; Fri, 2 Jun 2000 11:35:01 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 14:42:24 -0400 Message-ID: From: Sharon Boeyen To: "'ietf-smime@imc.org'" Subject: SMIME cert dist draft and X.509 Date: Fri, 2 Jun 2000 14:42:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am not a regular participant on this mailing list, and therefore lack the history behind this draft. However, as editor of X.509, I'm wondering why this draft invents new data structures for requirements that, after a very quick review, I think that X.509 already has standardized structures to support. From a 509 perspective, I certainly want to understand any shortcomings that specification has with respect to meeting the needs of the applications that use public-key certificates. Regarding SMimeCapabilities themeselves; was the supportedAlgorithms attribute from 509 considered? If so, were there specific shortcomings that it had? Note that it is defined in X.509 as an attribute. Attributes can be stored in directories as part of entries (with or without being digitally signed and/or encrypted), they can be transferred in application protocols, they can be included in public-key and attribute certificates. Regarding the requirement to tie a set of supported algorithms to a specific certificate; the construct defined in the Internet draft is semantically an attribute certificate. Was an X.509 attribute certificate considered and rejected? If so, what were its deficiencies? Note that there are a number of ways to identify the holder of an X.509 attribute certificate. One of those is the hash of a public-key certificate. An attribute certificate that contained the hash of a public-key certificate and the supportedAlgorithms attribute seems to provide the functionality you're looking for. If you want a construct that includes several iterations (i.e. the set of algorithms for each public-key certificate), then the X.509 construct attributeCertificateAttribute seems to provide this because it is a multivalued attribute that contains values of the attributeCertificate construct. Again, these can be stored in directories, stored in files, transferred in application protocols etc. Regarding PKI path construction; this is an area where a number of different groups seem to be active. I'm curious why there would be an smime specific mechanism for this anyway, when if there really is a problem, its probably not unique to smime. PKIX seems like a better place to solve this problem. I'm not sure I really understand your proposed solution. Are you focused only on hierarchies or also addressing networked trust models? Why store the path with the subject's domain when its the relying party's domain where the information is needed. Why associate it with a user certificate at all, since the same path (less the user cert) can be reused for any user certs signed by the same CA? X.509 has a standard attribute called pkiPath that I think may satisfy the requirement. This attribute contains a sequence of CA-certificates and its intent is that it stores paths that are frequently used by the relying parties within the community of a given CA. As such, it can be used to reduce the number of network connections and directory (or other protocol) requests to external domains. It is intended to be an optional facility that may be useful in some environments, but not necessary in others. With respect to all of these, my view is that, if directories are being used as repositories for the information, then ALL public-key certificates issued to a user be stored in the userCertificate attribute of their directory entry. This eliminates the need for specialized application-specific tools on the relying party side to find application specific data. If there are enhanced mechansims that provide potential efficiencies in an application specific environment these should be optional enhancements and not eliminate the fundamental interoperability requirement to store information in a common place. I hold the same view with respect to the pkiPath attribute. If stored in a directory it should not eliminate the need to store information as defined in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate attributes. I apologize in advance if, due to my lack of knowledge of the history of this spec, I'm asking questions that have been previously dealt with and closed, but felt I should at least ask, in the capacity of X.509 editor. FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or pdf format from the following: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ This text has been approved by ITU and is the 2000 edition of X.509, although many of things I mention were in the 1997 3rd edition text as well. Sharon Sharon Boeyen Entrust Technologies sharon.boeyen@entrust.com From owner-ietf-smime Sun Jun 4 14:50:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01800 for ietf-smime-bks; Sun, 4 Jun 2000 14:50:35 -0700 (PDT) Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01793 for ; Sun, 4 Jun 2000 14:50:30 -0700 (PDT) Received: by vguard.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 00:58:55 +0200 Message-ID: From: Raviv Karnieli To: "Russell Housley (E-mail)" Cc: "SMIME WG (E-mail)" Subject: Multiple e-mail addresses Date: Mon, 5 Jun 2000 00:58:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, I attached the relevant paragraph from the last WG Minutes. I wonder if farther work was done on these issues, which I find very important for a workable S/MIMEv3 implementation. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Application of Attribute Certificates (AC) in S/MIME - Greg Colla Greg's briefing addressed the topic of checking the e-mail address of the signedData signer against the e-mail address in the signer's certificate. Greg briefed that there are problems with binding the subject's e-mail address with the subject's public key in an X.509 public key certificate such as: - Multiple e-mail addresses - Maintenance of e-mail addresses - Security Proxy (a proxy signs and decrypts on behalf of many users) - Privacy/Spam Greg briefed the following requirements: Address Aliasing: Associate a single entity with multiple e-mail addresses, with a single PKC. Secure Proxying: Associate multiple entities, each with their own e-mail address, with a common PKC. Address Sharing: Associate multiple entities, each with their own PKC, with a single e-mail address. Greg proposed the following: - Maintenance of e-mail addresses limits S/MIME usability - ACs can be used to cryptographically bind e-mail addresses with PK certificates - E-mail ACs provide a flexible solution for maintaining e-mail addresses - Supplements current infrastructure - Localized modifications required to S/MIME components to use E-mail ACs - E-mail ACs can be used to solve other S/MIME limitations ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Thanks, Raviv Karnieli - CTO Vanguard Security Technologies Ltd. Tel. +972-4-989-1311 Fax +972-4-989-1322 www.vguard.com raviv@vguard.com This message left my computer secured since I'm using MAILguardian Enterprise the first true end to end enterprise e-mail security solution that is policy based, centrally managed and totally transparent to the end users. You can get your own free evaluation copy of MAILguardian at http://www.vguard.com/prod.asp From owner-ietf-smime Sun Jun 4 14:50:37 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA01801 for ietf-smime-bks; Sun, 4 Jun 2000 14:50:37 -0700 (PDT) Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01792 for ; Sun, 4 Jun 2000 14:50:27 -0700 (PDT) Received: by vguard.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 00:58:52 +0200 Message-ID: From: Raviv Karnieli To: "'ietf-smime@imc.org'" Subject: RE: Final 29 March 2000 S/MIME WG Minutes Date: Mon, 5 Jun 2000 00:58:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, I was looking for Greg's briefing which was supposed to be stored at ftp://ftp.ietf.org/ietf/smime/ but could not find it. Can you point it out to me? Thanks, Raviv Karnieli - CTO Vanguard Security Technologies Ltd. Tel. +972-4-989-1311 Fax +972-4-989-1322 www.vguard.com raviv@vguard.com This message left my computer secured since I'm using MAILguardian Enterprise the first true end to end enterprise e-mail security solution that is policy based, centrally managed and totally transparent to the end users. You can get your own free evaluation copy of MAILguardian at http://www.vguard.com/prod.asp -----Original Message----- From: Pawling, John [mailto:John.Pawling@wang.com] Sent: Monday, May 08, 2000 10:51 PM To: SMIME WG (E-mail) Subject: Final 29 March 2000 S/MIME WG Minutes This message includes the minutes of the IETF S/MIME Working Group meeting held on 29 March 2000 in Adelaide, Australia. All briefing slides will be stored at: ftp://ftp.ietf.org/ietf/smime/. These minutes include comments from the briefing presenters. Reported by John Pawling. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Introductions - Russ Housley Russ reviewed the agenda as follows. Nobody objected to the agenda. Introductions Russ Housley Working Group Status Russ Housley Security Policies and Labels Russ Housley CERTDIST Draft Discussion Jim Schaad Symmetric Key Distribution Sean Turner DOMSEC Draft Discussion Bill Ottaway Interoperability Matrix Jim Schaad CMS/ESS Examples Paul Hoffman Crypto Algorithm Documents Russ Housley E-mail Addresses & Certificates Greg Colla S/MIME Freeware Library John Pawling Electronic Signature Formats John Ross Wrap up Russ Housley +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Working Group Status - Russ Housley Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards: RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999 RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999 RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999 RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999 RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999 RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME. R. Zuccherato. March 2000. [Informational] The aforementioned documents must meet the following requirements to become Draft Standards: 1) Meet requirements documented in RFC 2026 2) Stable, mature, and useful specification 3) At least two independent and interoperable implementations from different code bases 4) Draft Standards cannot reference Proposed Standard RFCs or Experimental RFCs, so the aforementioned RFCs are blocked until the PKIX Certificate and CRL Profile "Son-of-RFC 2459" Internet-Draft (I-D) (draft-ietf-pkix-new-part1-01.txt) progresses to Draft Standard. Russ stated that Jim Schaad has developed an interoperability matrix for RFCs 2630 through 2634. Once completed, the matrix will indicate which features have and have not been implemented. So far, Microsoft and J.G. Van Dyke and Associates (VDA) have provided input to the interoperability matrix. Russ asked that other organizations that have developed S/MIME v3 capabilities should contribute to the matrix. Russ stated that testing of the example data included in the "Examples of S/MIME Messages" I-D is providing informal inputs for the matrix. Paul Hoffman stated that that other code bases also need to be tested. He welcomed feedback from novice developers. He has offered to coordinate interoperability testing. In the past, Paul has coordinated face-to-face SecureConnect interoperability events. He believes that future interoperability testing will not be face-to-face, but will be supported via a bulletin board or e-mail. He will announce any S/MIME inter events on the S/MIME WG mail list. Those events will be discussed in detail on the S/MIME developers mail list +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Mapping Company Classification Policy to the S/MIME Security Label - Russ Housley The "Implementing Company Classification Policy with the S/MIME Security Label" I-D, , December 1999, was authored by Weston Nicolls. It is planned that the document will become an Informational RFC. It describes how the ESS Security Label can be used to implement an organizational security policy. It includes three organizational examples: Whirlpool, Caterpillar and Amoco. One use of this document is to provide sample policies for interoperability testing. The document includes the security policy for Amoco Corporation as follows: - Confidentiality: General, Confidential, Highly Confidential - Integrity: Minimum, Medium, Maximum It includes the security policy for Caterpillar Inc as follows: - Confidentiality: Public, Confidential Green, Confidential Yellow, Confidential Red It includes the security policy for Whirlpool Corporation as follows: - Confidentiality: Public, Internal, Confidential - Additional marks at discretion of owner: - Privacy Marks? - Security Categories? - Do they require access control? Way Forward: - Support interoperability testing - Need to assign Object Identifiers: IETF values for this document and testing - Organizations assign their own After discussion with Weston Nicolls, who could not be present at this meeting, three object identifiers were assigned to permit the Whirlpool, Caterpillar and Amoco security policies to be used in interoperability testing. These object identifiers are not the ones that will be used by the companies, rather they are intended for testing. The object identifiers are: -- S/MIME Working Group Object Identifier Registry id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } -- Test Security Policies Arc id-tsp OBJECT IDENTIFIER ::= { id-smime 7 } -- Test Security Policies id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 } id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 } id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 } +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CERTDIST Draft Discussion - Jim Schaad Jim discussed the Certificate Distribution Specification I-D , October 20, 1999. The CERTDIST I-D was submitted for S/MIME WG "last call" for comments on 22 October 1999. Jim stated that he received comments regarding the following topics: - LDAP Directory Attribute layout - Additional arguments against CERTDIST Section 2 (current methods of publishing certificates) - miscellaneous minor comments Jims stated that he plans to publish an updated version of the CERTDIST I-D soon. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Symmetric Key Distribution - Sean Turner Sean discussed the S/MIME Symmetric Key Distribution I-D, , December 20, 1999. He stated that the design goals are to provide a transport independent mechanism for distribution of symmetric keys to a group of users. The mechanism must use RFC 2630. It must maximize the reuse of existing group/list management techniques (listserv, majordomo, etc). Seam explained the diagrams included in the I-D. Sean stated that he did not know of any patents regarding the secure distribution of symmetric keys. He asked if anybody else knew of any patents. Nobody replied. Paul Hoffman pointed out that the majordomo mail list server software does not support all mail list features. He stated that the SYMPA mail list server includes a database and rich set of features. Paul also pointed out that customers ask him on a monthly basis for secure mail list capabilities, so he knows that there are real requirements for these capabilities. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DOMSEC Draft Discussion - Bill Ottaway Bill presented a briefing regarding the "Domain Security Services Using S/MIME" I-D . He stated that there are minor differences between the -03 and -04 drafts as follows: - DOMSEC signatures are now added by encapsulation only. (Used to allow parallel signatures). - Allows order of third party signature application to be known. - More secure. - Section four re-written to aid understanding Bill discussed the proposed solution to an issue raised during the December 1999 S/MIME WG meeting. From those minutes: "Jim Schaad recommended that the domain name should be exactly matched. Jim also pointed out that RFC 2630 states that the content type should be id-data when there are no signers of a signedData object." Bill proposes that the original domain naming conventions should be preserved. Bill briefed that the users "must always rely on the CA to police naming conventions." Bill addressed Jim's other comment by adding text to the case when no originator signature is present to state that the eContentType will be id-data as specified in CMS. However, the eContent will contain the unsigned message instead of being left empty as suggested in CMS (section 2). This allows the DOMSEC signature to cover the message which does not have an originator signature. Bill stated that an object identifier must be obtained for the id-signatureType attribute. He believes that the document is ready for working group last call. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Interoperability Matrix - Jim Schaad Jim developed an interoperability matrix for RFCs 2630 through 2634. Jim has documented the features supported by Microsoft. VDA provided input to Jim regarding the capabilities of the S/MIME Freeware Library (SFL). VDA also provided input regarding interoperability testing conducted between the SFL and Microsoft. Jim asked for others to submit input to him at jimsch@nwlink.com. Jim also pointed out that there are some minor comments/questions to the RFCs that accompany the matrix. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Examples of S/MIME Messages - Paul Hoffman Paul stated that the "Examples of S/MIME Messages" I-D needs more input. He stated that VDA had tested the samples in the document and was planning to provide further sample data for inclusion in the document. He stated that the document is valuable because it includes the ASN.1 encoded examples. He stated that there is sample data that can be extracted using a Perl script that is also included in the document. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME WG Cryptographic Algorithm Specification - Russ Housley Russ briefed that the current S/MIME WG charter states: "The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of "mandatory to implement" algorithms may be selected." Russ briefed that the following I-Ds document the use of crypto algorithms with RFC 2630: 1) Use of the CAST-128 Encryption Algorithm in CMS, 2) CMS KEA and SKIPJACK Conventions, 3) CMS RSAES-OAEP Conventions, 4) Elliptic Curve S/MIME, 5) Incorporation of IDEA Encryption Algorithm in S/MIME Russ said that the following question was raised on the S/MIME WG mail list: "Should the specifications be published as Standards Track RFCs or Informational RFCs?" Russ stated that "mandatory-to- implement" algorithms will be published as Standards Track RFCs. He pointed out that the current S/MIME WG charter also states that complete algorithm specifications will be published as Standards Track RFCs. Jeff Schiller stated that he believes that all drafts describing the details of a crypto algorithm must be Informational because the IETF cannot control the definition of the crypto algorithms. Jeff further stated that he believes that all documents describing how crypto algorithms can be used with an IETF protocol can be Standards Track because the IETF can control the use of the crypto algorithms. He further stated that all documents describing how secret or proprietary crypto algorithms can be used can not be Standards Track. Russ applied Jeff's recommendations to the aforementioned list of I-Ds: 1) The "Use of the CAST-128 Encryption Algorithm in CMS" I-D can be a Standards Track document because the CAST 128 algorithm description is freely available. 2) The "CMS KEA and SKIPJACK Conventions" I-D can not be a Standards Track document because the U.S. Government has not freely published the description of the FORTEZZA 80-bit wrap function used to wrap the 80-bit SKIPJACK content encryption key. 3) The "CMS RSAES-OAEP Conventions" I-D can be a Standards Track document because the PKCS #1 v2.0 algorithm description is freely available. 4) The "Elliptic Curve S/MIME" I-D can be a Standards Track document because the algorithms are documented in ANSI X9.62 and ANSI X9.63. Paul Hoffman said that someone told him that Certicom has patents or pending patents on all of the "interesting and useful" curves. Russ agreed that Standards Track could only be achieved if the appropriate patent statements were made by Certicom or any other patent holder. 5) The "Incorporation of IDEA Encryption Algorithm in S/MIME" I-D can not be a Standards Track document because the IDEA crypto algorithm description is not freely available. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Application of Attribute Certificates (AC) in S/MIME - Greg Colla Greg's briefing addressed the topic of checking the e-mail address of the signedData signer against the e-mail address in the signer's certificate. Greg briefed that there are problems with binding the subject's e-mail address with the subject's public key in an X.509 public key certificate such as: - Multiple e-mail addresses - Maintenance of e-mail addresses - Security Proxy (a proxy signs and decrypts on behalf of many users) - Privacy/Spam Greg briefed the following requirements: Address Aliasing: Associate a single entity with multiple e-mail addresses, with a single PKC. Secure Proxying: Associate multiple entities, each with their own e-mail address, with a common PKC. Address Sharing: Associate multiple entities, each with their own PKC, with a single e-mail address. Greg proposed the following: - Maintenance of e-mail addresses limits S/MIME usability - ACs can be used to cryptographically bind e-mail addresses with PK certificates - E-mail ACs provide a flexible solution for maintaining e-mail addresses - Supplements current infrastructure - Localized modifications required to S/MIME components to use E-mail ACs - E-mail ACs can be used to solve other S/MIME limitations Greg summarized by stating that his proposal provides a strategy for removing email addresses from PK certificates. Greg's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding his proposal. Paul Hoffman stated that there are not many deployed ACs and that most companies have not implemented ACs. Paul stated his concern that the AC proposal will add confusion to and delay the deployment of S/MIME v3. He stated that ACs can be used in the future to solve problems. Greg Colla rebutted that they face these problems today (i.e. associated with binding e-mail addresses with public keys). Jim Schaad stated the following comments/questions regarding Greg's proposal: 1) Two directory lookups will be required for each recipient of an encrypted message. This added time delay will decrease overall performance. 2) How does this help keep email addresses private? People will mail ACs in messages. A "spam harvester" could obtain the e-mail addresses out of messages in transit or out of the directory. 3) Solves internal/external problem. 4) Favors this approach for gateway address identification. 5) Agrees with Paul Hoffman's comments regarding adding confusion. An attendee stated that CAs issue certificates and ISPs issue addresses. He asked whether Greg's proposal assumes that these two entities work closely together. Greg answered that an ISP could use an RA to create certificates. A system administrator could generate the AC. He made the point that the public key certificate generation is much more important. Another attendee stated that he doesn't agree that including e-mail addresses in certs is a problem. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Freeware Library (SFL) - John Pawling John provided an update briefing regarding the SFL which is a freeware implementation of RFC 2630 and RFC 2634. The SFL can be used with the Crypto++ freeware library to implement RFC 2631. The SFL provides functions to support use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL. John briefed that on 14 January 2000, the U.S. Department of Commerce published revisions to the Export Administration Regulations that changed the U.S. Government's encryption export policy. In accordance with these revised regulations, the unencumbered SFL source code is now freely available to everyone at: http://www.armadillo.huntsville.al.us/software/smime. Organizations can use the SFL as part of their applications without paying any royalties or licensing fees. There is a public license associated the SFL. The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA is developing the capability for the SFL to use any security library that provides a PKCS #11 interface. John stated that VDA had used the SFL to perform a significant amount of S/MIME v3 interop testing. VDA tested the majority of features in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs 2632 and 2633. VDA used the SFL to successfully process and produce the majority of features documented in "Examples of S/MIME Messages". A summary of the test results was sent to the S/MIME WG examples mail list . Complete test drivers and test data is available with the SFL. S/MIME v3 interoperability testing between the SFL and Microsoft successfully tested almost all signedData and envelopedData features using mandatory, RSA and Fortezza algorithm suites. For example, the SFL (using Crypto++) exchanged E-S D-H-protected envelopedData with Microsoft. Almost all of the ESS features were tested. For example, successful signed receipt interoperability testing was performed between the SFL and Microsoft. VDA verified that the SFL can produce and process the majority of the features documented in Jim Schaad's S/MIME v3 interoperability matrix. John sent the matrix to which VDA added the SFL test results to Jim Schaad for incorporation into the master S/MIME WG matrix. VDA developed sample objects that illustrate each feature in the matrix that the SFL supports. Complete test drivers and test data are available with the SFL. SFL interoperability testing is automated through use of test drivers and configuration files so it can be easily repeated and modified by VDA or independently by a third party. A third party could enhance the test drivers or incorporate them in an application such as an S/MIME interoperability testing auto-responder which organizations could use to test their S/MIME implementations. John also provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 version 3 certification path verification as specified in the 1997 X.509 Recommendation (except Delta CRLs are not implemented). The CML: validates X.509 certification paths and CRLs; provides local certificate/CRL storage functions; and provides remote directory retrieval via LDAP. The CML uses the Certificate Path Development Library (CPDL) developed by Cygnacom Solutions to robustly build certification paths including cross certificates. The CML complies with the majority of the RFC 2459 requirements. Organizations can use the CML as part of their applications without paying any royalties or licensing fees (see CML Public License). All CML source code is provided. CML is available at: http://www.armadillo.huntsville.al.us/software. John also discussed the VDA-enhanced SNACC Abstract Syntax Notation One (ASN.1) library that implements the Distinguished Encoding Rules (DER). John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the SFL and CML. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ETSI Electronic Signature Formats - John Ross John briefed regarding electronic signature formats for long term electronic signatures as part of the ETSI Electronic Signature Infrastructure Standardisation. John briefed that Special Task Force (STF) 155 includes: Task 1: Policies for Certificate Service Providers (CSP). Policy Requirements on CSP issuing Qualified Certificates Task 2: Electronic Signature Formats ETSI ES 201 733 & this Informational RFC Task 3: Profile for Qualified Certificates Task 4: Profile for TimeStamping Services John discussed the "Electronic Signature Formats for long term electronic signature" I-D, . John briefed that this document is proposed as an Informational RFC. It defines the format of an electronic signature that can remain valid over long periods. It includes features which can provide evidence as to its validity even if the signer later attempts to deny (repudiate) the validity of the signature. John stated that the contents of this Informational RFC will be technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C). He noted that the authors do not provide the IETF with any rights other than to publish as an Internet-Draft. John briefed that this document builds on other IETF standards such as RFC 2630 and RFC 2459. It will also build on coming standards such as the PKIX Timestamping protocol and PKIX AC profile. John discussed the proposal to split the draft document into two RFCs: one RFC dealing only with ES formats, the other one dealing only with a Signature Policy format. In such a case, the basis of this split will be, sections 6 and annex C will be removed from this document and placed in another RFC dealing with Signature policies. Also, the signature policy ASN.1 will be removed the current ASN.1 modules in annex A and placed in a new ASN.1 module in the other RFC dealing with Signature Policies. A separate OID for the Signature Policy arc would ease separation. Denis Pinkas made the point that the SigningCertificate signed attribute provides information about the signer and indicates the signer's AC that indicates which role the signer used to sign the data. The point was made that the Signature policy Identifier attribute is used by the signer to indicate the signature policy under which he is signing. The Signature policy Identifier attribute will contain a hash of the signature policy. The esformats-00 I-D provides further details regarding the definition and use of signature policies. John made the point that the esformats-00 I-D must be equivalent ETSI ES 201 733 V.1.1.1, so major changes can't be made to the esformats-00 I-D. Sean Turner asked how the ETSI Electronic Signature format relates to the timestamping work being done in the PKIX WG. Denis Pinkas answered that the ETSI Electronic Signature work uses CMS and will build on the PKIX Timestamping protocol. Mike Myers asked if the PKIX Data Validation and Certification Server (DVCS) Protocols would satisfy the ETSI Electronic Signature requirements. Peter Sylvester said that the DVCS protocol could include the ETSI Electronic Signature information. Denis stated the protocols could be used together, but don't have to be. Sean Turner asked if the S/MIME WG cared about the contents of the esformats-00 I-D, since they can't change it anyway. John Ross replied that the signature policy portion of the I-D can be changed, but that the Electronic Signature format can not be changed. John welcomed input to the signature policy portion of the I-D. Russ Housley asked if the signature policy portion of the I-D was covered under the ETSI copyright. John Ross said that it was. He further stated that they are working on getting the copyright rules relaxed regarding this topic. ETSI may split the ES 201 733 V.1.1.1 document into two parts to be consistent with a split in the esformats-00 I-D. A straw poll of the attendees favored splitting the esformats-00 I-D. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Wrap Up - Russ Housley Russ stated that the "Use of the CAST-128 Encryption Algorithm in CMS" I-D was in working group last call. Jim Schaad stated that he had provided comments to the document. Russ stated that a new draft of the I-D will be submitted for IETF-wide last call. Russ stated that he would like to issue last call for the "Password-based Encryption for S/MIME" I-D. Jim Schaad stated that he had provided significant comments to the document. John Pawling pointed out that several people had questioned why the I-D defined yet another key wrapping algorithm. Russ said that Peter Gutmann needs to address these comments on the mail list. Russ pointed out that the process of transforming a password to a key would be documented in a separate RFC. Russ discussed the "Compressed Data Content Type for S/MIME" I-D. Peter Gutmann sent a message to the S/MIME WG mail list asking: "Does anyone have any further thoughts on compression as a CMS content type vs a MIME type?" Russ said that the S/MIME WG needed to make a decision regarding Peter's question. Paul Hoffman stated that compression has been discussed on the MIME mail list, but it has not been standardized. He said that the issue needs to get resolved. Russ stated that Jeff Schiller recommended that the S/MIME WG "just do it" because the issue needs to be resolved for efficiency purposes. Russ took a straw poll and only three people expressed an opinion. Meeting adjourned. From owner-ietf-smime Mon Jun 5 06:11:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA11976 for ietf-smime-bks; Mon, 5 Jun 2000 06:11:28 -0700 (PDT) Received: from rmx470-mta.mail.com (rmx470-mta.mail.com [165.251.48.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11972 for ; Mon, 5 Jun 2000 06:11:26 -0700 (PDT) Received: from web622-wrb.mail.com (web622-wrb.mail.com [165.251.33.62]) by rmx470-mta.mail.com (8.9.3/8.9.3) with SMTP id JAA03785 for ; Mon, 5 Jun 2000 09:19:36 -0400 (EDT) Message-ID: <386162564.960211175692.JavaMail.root@web622-wrb.mail.com> Date: Mon, 5 Jun 2000 09:19:32 -0400 (EDT) From: Erynn Schmidt To: ietf-smime@imc.org Subject: s/mime v2 vs. v3 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 192.91.146.35 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello I'm researching the differences between S/MIME v2 and v3. I was wondering if there was a paper that had these differences listed. Any help would be greatly appreciated. Thanks Erynn From owner-ietf-smime Mon Jun 5 22:33:06 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA06464 for ietf-smime-bks; Mon, 5 Jun 2000 22:33:06 -0700 (PDT) Received: from gate2.healthware.on.ca ([209.167.93.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA06455 for ; Mon, 5 Jun 2000 22:33:05 -0700 (PDT) Message-Id: <200006060533.WAA06455@ns.secondary.com> Received: from host ([63.21.182.114]) by gate2.healthware.on.ca (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id ca; Mon, 5 Jun 2000 20:03:36 -0400 From: "Archie Reed" Subject: Desktop Artwork For Your Computer ! To: art38d X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Mon, 05 Jun 2000 19:12:30 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA06458 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: http://www.shoopdogg.com/sdgcd/sdgcd.html More than just Wallpaper. The ShoopDogg Graphics CD-Rom takes it to a new evel. Illustrated Desktop Art. Is there a way to wake up every orning o a new Desktop Wallpaper Celebrity for your computer? Now there is. http://www.shoopdogg.com/sdgcd/sdgcd.html Desktop Illustrations as seen on Sung Hi Lee, Kaila Yu, Linda Tran, & Sae arks web sites to mention a few. Over 60 inter-net models to view. Hundreds of Illustrated Desktop Wallpaper. Plus, many surreal world Illustrations and artwork. Click Here To Get Sample http://www.shoopdogg.com/sdgcd/sdgcd.html ********************************************************* You can have your address removed from our database by replying to: mailto:drisck@netscape.net?subject=remove ********************************************************* From owner-ietf-smime Wed Jun 7 22:37:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29457 for ietf-smime-bks; Wed, 7 Jun 2000 22:37:22 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29453 for ; Wed, 7 Jun 2000 22:37:20 -0700 (PDT) Received: from jimsch1t (ip191.du1.bel.nwlink.com [209.20.136.191]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id WAA24681; Wed, 7 Jun 2000 22:45:37 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "David P. Kemp" , Subject: RE: Cert Dist Changes Date: Wed, 7 Jun 2000 22:46:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200006021448.KAA07245@roadblock.missi.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of David P. Kemp > Sent: Friday, June 02, 2000 7:52 AM > To: ietf-smime@imc.org > Subject: RE: Cert Dist Changes > > > > > From: "Jim Schaad" > > To: "David P. Kemp" , , > > > Subject: RE: Cert Dist Changes > > Date: Thu, 1 Jun 2000 21:34:34 -0700 > > > > I am a bit loss for words. Are you saying that data is to > appear in one and > > only one location in the directory and not to be duplicated? > If this is not > > the case then I don't see your problem although consistancy can > be a problem > > depending on the different tools used to update the directory > for different > > purposes. (A mail program publishing information vs an access control > > program (such as the Win2K directory might not keep/correctly update all > > fields.) > > > > There is nothing that does not let you put things into the > userCertificate > > and caCertificate fields, however many programs only update the > > userCertificate field at present. The code that I wrote while > at Microsoft > > would publish into both the userSMimeCertificate and > userCertificate fields > > but ignored the caCertificate field as this exists only on CAs. > This means > > that if a user publishes a certificate in a different directory > (possibly > > unaccessable) directory, the client has no way of getting to CA > > certificates, thus for the general case caCertificates is unuseful. > > > Jim, > > That is precisely the situation (CA certificates not being accessible > to all consuming applications) I think we should be trying to avoid. > > If you start with a directory environment where caCertificate is not > useful, and you want to allow a particular application (S/MIME) to > operate, you have two possible courses of action: > > 1) encourage directory administrators to make caCertificate useful, or > 2) encourage directory administrators to populate an S/MIME-specific > attribute to bypass the need for caCertificate. > > I believe that option 2 is harmful to the Internet environment. > Once administrators have made the effort to populate a repository with > certificates, the identical repository should be usable by S/MIME, SSL, > IPsec, and other applications. Developing a stovepipe (single-purpose) > solution is easier in the short run, but will cost us dearly later. > > Regards, > Dave > Dave, If this is what you believe, I encourage you to immeadiately put a draft of some type in the PKIX working group that will allow me to do path discovery in a non-X509 directory environment (the internet) where all information currently in the certificate is X509 based. When I have looked that the problem I have come to the conclusion that the problem is not solvable in the general case given: 1) X509 certificates are based on X509 names but directory lookup is not for non-X509 directories. 2) Attempting to identify the directory that needs to be used for doing the lookup is not presently doable (what is the LDAP directory that I should use for c=us, o=missi). CRLs may be found though the CDP, but certificates cannot be found from the DN. jim From owner-ietf-smime Wed Jun 7 22:37:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29449 for ietf-smime-bks; Wed, 7 Jun 2000 22:37:17 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29445 for ; Wed, 7 Jun 2000 22:37:14 -0700 (PDT) Received: from jimsch1t (ip191.du1.bel.nwlink.com [209.20.136.191]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id WAA24675; Wed, 7 Jun 2000 22:45:34 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "Sharon Boeyen" , Subject: RE: SMIME cert dist draft and X.509 Date: Wed, 7 Jun 2000 22:46:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sharon, There were a number of limitations that are in X509 that I was trying to overcome with this draft: The supportedAlgorithms field was not used for two reasons, first I did not know about it when this started and secondly attribute certificates were not defined at the time the problem was addressed, thus they were not a part of every S/MIME application already. The use of the SignedData structure means that we are re-using already existing code in every S/MIME application. (The exact same mechinism is used for transfering the information when sending a signed message between two entities.) Given that we are living in an LDAP world rather than an X509 world, using isser DNs of certificates to attempt to find an issuer certificate is an extremely difficult problem. Add to this the questions of companies/individuals not publishing intermeadiate CA certificates or making them private (although the CRL might be available from a non-directory location) and I don't know that in the internet world that the certificate retrevial portion of path construction is viable. While I agree that this problem might have been better considered in the PKIX working group as the problem is universion, however the problem and the solution was first found by S/MIME developers and the chair of the group agreed that it was a reasonable problem to be put before the group. Additionally, the solution used some items that were defined by the working group in the S/MIME documents rather than in PKIX documents. Lastly, the PKIX group is still very X509 directory centric in many of it's solutions while the S/MIME working group is extremely LDAP centric. Thus what seems to be a problem for the S/MIME working group might not be a problem for the PKIX working group (such as finding CA certificates without an X509 directory). Additionally please note that we have not solved the general path construction problem, we have only made it easier (since the holder of the certificate is in a better situation to build their own path) for the sender to avoid the problem. In the event that the PKIX group came up with a viable method of doing path discovery then this draft can be revised so that the full path information was not required in the attribute even though there are situations (i.e. offline or non-directory location of the attribute) where it might be useful. jim schaad -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Sharon Boeyen Sent: Friday, June 02, 2000 11:42 AM To: 'ietf-smime@imc.org' Subject: SMIME cert dist draft and X.509 I am not a regular participant on this mailing list, and therefore lack the history behind this draft. However, as editor of X.509, I'm wondering why this draft invents new data structures for requirements that, after a very quick review, I think that X.509 already has standardized structures to support. From a 509 perspective, I certainly want to understand any shortcomings that specification has with respect to meeting the needs of the applications that use public-key certificates. Regarding SMimeCapabilities themeselves; was the supportedAlgorithms attribute from 509 considered? If so, were there specific shortcomings that it had? Note that it is defined in X.509 as an attribute. Attributes can be stored in directories as part of entries (with or without being digitally signed and/or encrypted), they can be transferred in application protocols, they can be included in public-key and attribute certificates. Regarding the requirement to tie a set of supported algorithms to a specific certificate; the construct defined in the Internet draft is semantically an attribute certificate. Was an X.509 attribute certificate considered and rejected? If so, what were its deficiencies? Note that there are a number of ways to identify the holder of an X.509 attribute certificate. One of those is the hash of a public-key certificate. An attribute certificate that contained the hash of a public-key certificate and the supportedAlgorithms attribute seems to provide the functionality you're looking for. If you want a construct that includes several iterations (i.e. the set of algorithms for each public-key certificate), then the X.509 construct attributeCertificateAttribute seems to provide this because it is a multivalued attribute that contains values of the attributeCertificate construct. Again, these can be stored in directories, stored in files, transferred in application protocols etc. Regarding PKI path construction; this is an area where a number of different groups seem to be active. I'm curious why there would be an smime specific mechanism for this anyway, when if there really is a problem, its probably not unique to smime. PKIX seems like a better place to solve this problem. I'm not sure I really understand your proposed solution. Are you focused only on hierarchies or also addressing networked trust models? Why store the path with the subject's domain when its the relying party's domain where the information is needed. Why associate it with a user certificate at all, since the same path (less the user cert) can be reused for any user certs signed by the same CA? X.509 has a standard attribute called pkiPath that I think may satisfy the requirement. This attribute contains a sequence of CA-certificates and its intent is that it stores paths that are frequently used by the relying parties within the community of a given CA. As such, it can be used to reduce the number of network connections and directory (or other protocol) requests to external domains. It is intended to be an optional facility that may be useful in some environments, but not necessary in others. With respect to all of these, my view is that, if directories are being used as repositories for the information, then ALL public-key certificates issued to a user be stored in the userCertificate attribute of their directory entry. This eliminates the need for specialized application-specific tools on the relying party side to find application specific data. If there are enhanced mechansims that provide potential efficiencies in an application specific environment these should be optional enhancements and not eliminate the fundamental interoperability requirement to store information in a common place. I hold the same view with respect to the pkiPath attribute. If stored in a directory it should not eliminate the need to store information as defined in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate attributes. I apologize in advance if, due to my lack of knowledge of the history of this spec, I'm asking questions that have been previously dealt with and closed, but felt I should at least ask, in the capacity of X.509 editor. FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or pdf format from the following: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ This text has been approved by ITU and is the 2000 edition of X.509, although many of things I mention were in the 1997 3rd edition text as well. Sharon Sharon Boeyen Entrust Technologies sharon.boeyen@entrust.com From owner-ietf-smime Thu Jun 8 09:08:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28608 for ietf-smime-bks; Thu, 8 Jun 2000 09:08:26 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28598 for ; Thu, 8 Jun 2000 09:08:24 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D37FA42U@mta5.rcsntx.swbell.net> for ietf-smime@imc.org; Thu, 8 Jun 2000 11:06:02 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:02 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-smime@imc.org Message-id: <0FVU00DLMFDZ2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-ietf-smime Thu Jun 8 11:44:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04528 for ietf-smime-bks; Thu, 8 Jun 2000 11:44:54 -0700 (PDT) Received: from rgaexconn.rgare.com ([198.190.171.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04524 for ; Thu, 8 Jun 2000 11:44:53 -0700 (PDT) Received: by RGAEXCONN with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 13:52:38 -0500 Message-ID: From: "Hellrung, Lisa" To: "'ietf-smime@imc.org'" Subject: Signed message Date: Thu, 8 Jun 2000 13:52:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I was wondering if someone could help me out with the syntax of a signed message? I am able to send signed and encrypted e-mail but if I only sign that e-mail, it will either show up in Outlook and Outlook Express as a regular message or signed but "Message has been tampered with" error. When sent with "Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="=====NextPart_qaNWAwffsV5PxkAy7ndv" Message "Content-Type: application/x-pkcs7-signature;" + vbCrLf + " name=""smime.p7s""" + vbCrLf "Content-Transfer-Encoding: base64" + vbCrLf "Content-Disposition: attachment;" + vbCrLf + " filename=""smime.p7s""" + vbCrLf + vbCrLf Encoded signed message It appears as a normal mail message. When sent with "Content-Type: application/pkcs7-mime;smime-type=signed-data;name=smime.p7m" + vbCrLf "Content-Type: application/pkcs7-mime;" & vbCrLf + " name=""smime.p7m""" + vbCrLf "Content-Transfer-Encoding: base64" + vbCrLf "Content-Disposition: attachment;" + vbCrLf + " filename=""smime.p7m""" + vbCrLf + vbCrLf encoded message It appears as signed but invalid because message has been tampered with. If anyone could help me to correct this problem, I would greatly appreciate it. Also, the first message works when later encrypted. Thanks. From owner-ietf-smime Thu Jun 8 12:58:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05796 for ietf-smime-bks; Thu, 8 Jun 2000 12:58:10 -0700 (PDT) Received: from rgaexconn.rgare.com ([198.190.171.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05792 for ; Thu, 8 Jun 2000 12:58:08 -0700 (PDT) Received: by RGAEXCONN with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 15:05:59 -0500 Message-ID: From: "Hellrung, Lisa" To: "'ietf-smime@imc.org'" Subject: Date: Thu, 8 Jun 2000 15:05:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Erik, I changed the second message to opaque-signed and removed the second header but still no getting a security warning that the message has been tampered with. "Content-Type: application/pkcs7-mime;smime-type=opaque-signed;name=smime.p7m" + vbCrLf "Content-Transfer-Encoding: base64" + vbCrLf "Content-Disposition: attachment;" + vbCrLf + " filename=""smime.p7m""" + vbCrLf + vbCrLf Encoded message Any other ideas on how to make this work? Thanks. Lisa ----- Original Message ----- From: "Erik Neuenschwander" > To: "Hellrung, Lisa" > Sent: Thursday, June 08, 2000 2:16 PM Subject: Re: Signed message > This should be opaque-signed, the second kind, the kind that you say gives > you errors. How does this one turn out? > > see my one inline comment > > ----- Original Message ----- > From: "Hellrung, Lisa" > > To: > > Sent: Thursday, June 08, 2000 11:52 AM > Subject: Signed message > > > > I was wondering if someone could help me out with the syntax of a signed > > message? I am able to send signed and encrypted e-mail but if I only > sign > > that e-mail, it will either show up in Outlook and Outlook Express as a > > regular message or signed but "Message has been tampered with" error. > > > > When sent with > > > > "Content-Type: multipart/signed; > protocol="application/x-pkcs7-signature"; > > micalg=SHA1; > > boundary="=====NextPart_qaNWAwffsV5PxkAy7ndv" > > > > Message > > > > "Content-Type: application/x-pkcs7-signature;" + vbCrLf + " > > name=""smime.p7s""" + vbCrLf > > "Content-Transfer-Encoding: base64" + vbCrLf > > "Content-Disposition: attachment;" + vbCrLf + " > > filename=""smime.p7s""" + vbCrLf + vbCrLf > > Encoded signed message > > > > It appears as a normal mail message. > > > > When sent with > > > > "Content-Type: > application/pkcs7-mime;smime-type=signed-data;name=smime.p7m" > > + vbCrLf > > "Content-Type: application/pkcs7-mime;" & vbCrLf + " > > name=""smime.p7m""" + vbCrLf > ^^^^^^^^^^^^ > Where is this second Content-Type header coming from? > > > "Content-Transfer-Encoding: base64" + vbCrLf > > "Content-Disposition: attachment;" + vbCrLf + " > filename=""smime.p7m""" > > + vbCrLf + vbCrLf > > encoded message > > > > It appears as signed but invalid because message has been tampered with. > > > > > > If anyone could help me to correct this problem, I would greatly > appreciate > > it. > > > > Also, the first message works when later encrypted. Thanks. > > > > > From owner-ietf-smime Fri Jun 9 12:47:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05505 for ietf-smime-bks; Fri, 9 Jun 2000 12:47:14 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05500 for ; Fri, 9 Jun 2000 12:47:12 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial04.spyrus.com [207.212.34.124]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA28172 for ; Fri, 9 Jun 2000 12:55:08 -0700 (PDT) Message-Id: <4.2.0.58.20000609082043.00a55a00@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 09 Jun 2000 08:36:23 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: draft-ietf-smime-idea-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Draft Authors: The Working Group Last Call is almost finished (it closes on Monday). I wanted to post the things that I noticed in the document that I have not seen posted by anyone else. In section 2, the document says: The identifier's parameters field contains the initial vector IV as an optional parameter. IDEA-CBCPar ::= SEQUENCE { IV OCTET STRING OPTIONAL -- exactly 8 octets } If IV is specified as above, it MUST be used as initial vector. In this case, the ciphertext MUST NOT include the initial vector. If IV is not specified, the first 64 bits of the ciphertext MUST be considered as the initial vector. However, this alternative of not including the IV SHOULD NOT be applied in S/MIME. First, please change "initial vector IV" to "initialization vector (IV)" or "initialisation vector (IV)" depending on you geographic preference (US English vs. UK English). Then, use IV throughout. Second, we have already seen messages requesting the removal of the SEQUENCE wrapper in the ASN.1. This should be done. The OPTIONAL is not needed either. In the AlgorithmIdentifier structure, the parameter is already OPTIONAL. I suggest: IDEA-CBC-IV ::= OCTET STRING -- exactly 8 octets Third, I would like to see the final sentence in the last paragraph reworded. I suggest: However, the IV MUST be included in the AlgorithmIdentifier parameter when IDEA is used with CMS. Later in section 2, the document says: The identifier's parameters field MUST be NULL. Many algorithms use this technique. Since the AlgorithmIdentifier parameters are OPTIONAL, the same semantics can be provided with fewer bits on the wire by requiring that the parameters field be absent. Please consider this alternative. In section 3.1, step 3, there is a typo. Please change ":=" to "=". Thanks for your attention, Russ From owner-ietf-smime Mon Jun 12 01:22:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA24681 for ietf-smime-bks; Mon, 12 Jun 2000 01:22:32 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24677 for ; Mon, 12 Jun 2000 01:22:30 -0700 (PDT) Received: from jimsch1t (ip171.du1.bel.nwlink.com [209.20.136.171]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id BAA04279 for ; Mon, 12 Jun 2000 01:21:53 -0700 (PDT) Reply-To: From: "Jim Schaad" To: Subject: RE: draft-ietf-smime-idea-03 Date: Mon, 12 Jun 2000 01:22:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <01FF24001403D011AD7B00A024BC53C594FB4F@mail.deming.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This has not been taken care of in the -04 draft. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell Sent: Friday, April 14, 2000 4:04 PM To: 'jimsch@nwlink.com'; ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 Agree. I think this should be 300D at the beginning, and trim the last two bytes off of both examples. Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, April 14, 2000 12:35 AM To: ietf-smime@imc.org Subject: draft-ietf-smime-idea-03 The S/MIME Capability sequences appear to be wrong. In section 4 paragraph 2, the text states that the parameters field must be absent, however the encoding sequence given has the parameters encoded as NULL. The same is true in paragraph 3 of the same section. jim http://www.nwlink.com From owner-ietf-smime Mon Jun 12 20:27:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11597 for ietf-smime-bks; Mon, 12 Jun 2000 20:27:54 -0700 (PDT) Received: from mail.harbourring.com.hk ([210.176.103.61]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11592 for ; Mon, 12 Jun 2000 20:27:50 -0700 (PDT) Message-Id: <200006130327.UAA11592@ns.secondary.com> Received: from host [38.26.242.148] by mail.harbourring.com.hk with ESMTP (SMTPD32-4.04) id AC2A95029E; Tue, 13 Jun 2000 11:23:38 +0800 From: "Tommy Davis" Subject: Disaster Recovery Planning #67A1 To: recove30c X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Mon, 12 Jun 2000 22:42:05 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA11593 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Business continuity and disaster recovery planning has now been made easier than ever with Version 7.3 of the Disaster Recovery System (DRS) product. DRS provides a plan for inaccessibility or inoperability (a disaster situation). DRS is an industry standard software product, used by thousands worldwide. DRS users are in large and small companies across a wide variety of industries. DRS conforms to federal regulations and meets insurance, auditing and legal requirements. DRS runs under Windows, with stand-alone and network versions available. DRS provides the most complete, easy-to-use product available today. To prove its value, a free trial is available. For more information, visit our web site at www.drsbytamp.com . Dealer and distributor inquiries are welcomed ***************************************************************** This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability.If you are a Washington, Virginia, or California resident please remove yourself. ==================================================== /////////////////////////////////////////////////// To be removed permanantly from this list reply to: mailto:bkf21b@netscape.net?subject=remove /////////////////////////////////////////////////// From owner-ietf-smime Thu Jun 15 02:23:41 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA10125 for ietf-smime-bks; Thu, 15 Jun 2000 02:23:41 -0700 (PDT) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA10120 for ; Thu, 15 Jun 2000 02:23:35 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 15 Jun 00 10:35:22 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id ; Thu, 15 Jun 2000 10:15:29 +0100 Message-ID: <608D67882786D211B1070090271E4CB990AC51@BJEX1> From: "Alan Shepherd" To: "'Frank W. Nolden'" cc: "ietf-smime" Subject: RE: Does Slime works fine with Windows 2000 PKI Date: Thu, 15 Jun 2000 10:15:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 15567CD0147430-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm jumping in too! I'd like to add that we have deployed the MaxWare LDAP proxy server for just this role in a large corporate in the UK. They have a PKI and wish to communicate externally using certificates from it, so we use the MaxWare software to control access to the directory information, specifically only allowing searches on mail addresses and the retrieval of certificates. This means that all other information in the corporate directory is still secure. Alan Shepherd. > -----Original Message----- > From: Frank W. Nolden [mailto:frank.nolden@maxware.nl] > Sent: 11 May 2000 16:17 > To: Walter Williams; Laurent Deffranne > Cc: ietf-smime > Subject: Re: Does Slime works fine with Windows 2000 PKI > > > Sorry for jumping into this discussion, which I find very > interesting. There > is a way of publishing certificates to the outside world > without opening up > the AD. I think Walter mentioned in already and that is > replicating only the > certificate information (with some minor additional information like > emailaddress, distinguished name, surname, tc) to an (LDAP) > directory that > is connected to the internet. Replicating this information > cannot be done > using the standard X.500 DISP protocol since Microsoft does > not support > that, but you can use LDIF files and other more sophisticated > tools like our > MaXware Directory Sync Engine. You could put LDAP proxy > servers (MaXware > also has these available as Innosoft does) in front of that > for security > purposes and attribute mapping. > > A major advantage is that you do not permit anyone in real > time either via a > proxy or not to access information in the AD. An extra (LDAP) > directory is > an extra security barrier to your AD and it will only publish the > information you want to be available on the web, without > risking access to > your AD and without configuring the Access Control in AD. > Regards, > > Frank Nolden > > > > ----- Original Message ----- > From: "Walter Williams" > To: "Laurent Deffranne" > Cc: "ietf-smime" > Sent: Thursday, May 11, 2000 15:57 > Subject: RE: Does Slime works fine with Windows 2000 PKI > > > > Active directory would expose a significant amount of > information you > might > > not want the external world to know, such as a complete > listing of all > your > > w2k computers and their roles in your network. You could > use a LDAP proxy > > server to provide what you want to the internet and keep the data in > active > > directory. Innosoft (Now purchased by IPlanet) makes such > a product. > There > > are probably others on the market. > > > > > -----Original Message----- > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > Sent: Thursday, May 11, 2000 9:48 AM > > > To: walter.williams > > > Cc: ietf-smime > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > What would happen if you want to open the directory to anonymous > > > access to the Web ? > > > In such a way that you could exchange S/MIME certs with > outside people ? > > > > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > 11/05/2000 15:35 > > > To: Laurent Deffranne/GKBCCB@GKBCCB > > > cc: ietf-smime%imc.org@Internet > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > Let me take the points one at a time and inline: > > > > > > > -----Original Message----- > > > > From: Laurent Deffranne [mailto:Laurent.Deffranne@dexia.be] > > > > Sent: Thursday, May 11, 2000 9:19 AM > > > > To: walter.williams > > > > Cc: ietf-smime > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > Walt, > > > > > > > > Do you mean that there are difficulties to access > through LDAP an > > > > Active Directory, as you want to read or use X509 certificates ? > > > > > > > > > > No. However, are you going to open your active directory to > > > anonymous LDAP > > > queries over the Internet? If not, are you limiting S/MIME to > > > internal use > > > only? If not then you are somewhat back to square one. > > > > > > > By the way,does somebody know issues about Active > Directory LDAP, > > > > or issues to read a certificate in an Active Directory ? > > > > > > This worked just fine for us here, but the problem we had > with AD was > that > > > it does not support inetOrgPerson, and thus can't easily be > > > synched up with > > > most external LDAP directories. You'll find you'll want > a metadirectory > > > connector to synch it with any external directory. > Again, this is not > an > > > issue if you're willing to directly expose AD to internet use. > > > > > > > > For me it would be a mistake to use now the "brand new" Active > > > > Directory, but if someone could tell me where I can find proofs > > > > of lack of compatibility (from Microsoft, there must be surely > > > > one of two), this would interrest me. > > > > > > > AD seems to work just fine, if you don't mind working with > > > something with a > > > proprietary schema. Any LDAP and S/MIME aware client we > pointed at it > > > understood the contents just fine, so the schema does not > seem to impact > > > client interoperability. > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > > > > > walter.williams%genuity.com@Internet > > > > 11/05/2000 14:54 > > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet > > > > cc: > > > > > > > > Subject: RE: Does Smime works fine with Windows 2000 PKI > > > > > > > > Laurent; > > > > > > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no > > > > less so than > > > > certs issued from Baltimore, Iplanet or any other CA vendor or > > > > product. The > > > > main issue is not will they work, but will you be able > to validate the > > > > certs. Unless the person issuing the cert from W2K has > > > provided you with > > > > their server's cert, or they have certified their CA with the > > > signature of > > > > the publicly known CAs you will not be able to easily verify > > > the signature > > > > to its source. This is not the most technically acurate way of > > > > saying this > > > > but I'm not awake yet. Baltimore has preregistered > there CA with the > > > > vendors distributing products, as has Verisign, Thaught, and > > > many others. > > > > Just make certain that you have the certificates for the W2K CA, > > > > and access > > > > to its revocation list so you can validate properly and > you'll be > fine. > > > > > > > > Walt Williams > > > > TSD-Systems > > > > Senior IT Analyst > > > > Genuity > > > > www.genuity.com > > > > > > > > Please note: GTE Internetworking is now Genuity. > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-smime@mail.imc.org > > > > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of > Laurent Deffranne > > > > > Sent: Thursday, May 11, 2000 5:45 AM > > > > > To: ietf-smime > > > > > Subject: Does Smime works fine with Windows 2000 PKI > > > > > > > > > > > > > > > Hi everybody, > > > > > > > > > > Just a question : > > > > > > > > > > Is there any known issues using S/MIME with > Win2000PKI-certificates > ? > > > > > More generally, are Win2000 certificates usable with (and > > > > > understood by ) the others mailers (especially Lotus Notes, > > > > > Netscape, Eudora +plug-in?) > > > > > > > > > > Isn't Baltimore Unicert a "better choice" due to its greater > > > > > compatibility ? > > > > > > > > > > Any advices are welcome. > > > > > > > > > > Regards, > > > > > > > > > > Laurent Deffranne > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------------------ This message is for the named person’s use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. From owner-ietf-smime Thu Jun 15 14:35:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04426 for ietf-smime-bks; Thu, 15 Jun 2000 14:35:50 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA04422 for ; Thu, 15 Jun 2000 14:35:49 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 15 Jun 2000 14:34:59 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 14:34:59 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C594FF4F@mail.deming.com> From: "Blake Ramsdell" To: "'jimsch@nwlink.com'" , ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 Date: Thu, 15 Jun 2000 14:34:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 1557938938068-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: And just to be clear, this absolutely must be fixed (either the text must be corrected to say that the parameters are encoded as ASN.1 NULL or the examples must be corrected as I have pointed out). The MUSTS in the current draft are contradictory. Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Monday, June 12, 2000 1:22 AM To: ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 This has not been taken care of in the -04 draft. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell Sent: Friday, April 14, 2000 4:04 PM To: 'jimsch@nwlink.com'; ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 Agree. I think this should be 300D at the beginning, and trim the last two bytes off of both examples. Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, April 14, 2000 12:35 AM To: ietf-smime@imc.org Subject: draft-ietf-smime-idea-03 The S/MIME Capability sequences appear to be wrong. In section 4 paragraph 2, the text states that the parameters field must be absent, however the encoding sequence given has the parameters encoded as NULL. The same is true in paragraph 3 of the same section. jim http://www.nwlink.com From owner-ietf-smime Fri Jun 16 00:14:20 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18114 for ietf-smime-bks; Fri, 16 Jun 2000 00:14:20 -0700 (PDT) Received: from smtp01.hk.linkage.net (smtp01.hk.linkage.net [210.184.16.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18110 for ; Fri, 16 Jun 2000 00:14:17 -0700 (PDT) Received: from novell.beautyforest.com.hk ([203.85.85.200]) by smtp01.hk.linkage.net (8.9.3/8.9.3) with ESMTP id PAA10139; Fri, 16 Jun 2000 15:11:19 +0800 (HKT) Received: from BEAUTY/SpoolDir by novell.beautyforest.com.hk (Mercury 1.48); 16 Jun 00 15:08:12 GMT+0800 Received: from SpoolDir by BEAUTY (Mercury 1.48); 16 Jun 00 14:45:09 GMT+0800 Received: from host (209.206.11.160) by novell.beautyforest.com.hk (Mercury 1.48) with ESMTP; 16 Jun 00 14:44:58 GMT+0800 From: "Owen Carlson" Subject: Your business depends on it #5192 To: biz2w9@smtp01.hk.linkage.net X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Fri, 16 Jun 2000 00:01:58 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <252666E95550@novell.beautyforest.com.hk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA18111 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Email marketing is starting to boom and you're probably wondering how you can capitalize on this phenomenal advertising method. Well..here is your chance! As e-commerce grows, you need to stay on top of your competition and keep up with the technology. GENIUS MARKETING STRATEGIES CAN HELP! We can target a market that will advertise your business effectively. NATIONWIDE OR LOCAL TARGETING IS AVAILABLE! You've probably seen millions of email addresses on CD's for $50 or lots of companies offering deals that seem too good to be true... Well, they are! We are professional email marketers who take pride in our excellent customer service. RATED #1 EMAIL MARKETERS IN ENTREPRENEUR MAGAZINE Get a head start on your competition today with FREE ADVERTISING CONSULTING from Genius Marketing Strategies. Reply to mailto:markstrat@POPULUS.net Please include: (All info is required for a response) Name: e-mail address: Phone# Web site address: Best time to reach: Preferred to be contacted by EMAIL or PHONE We accept: VISA, MASTER CARD, AND AMERICAN EXPRESS OR CHECK BY FAX OR PHONE. ******************************************************* Please remove at: mailto:twentytwo4424@netscape.net?subject=remove ******************************************************* From owner-ietf-smime Fri Jun 16 10:27:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19926 for ietf-smime-bks; Fri, 16 Jun 2000 10:27:44 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19922 for ; Fri, 16 Jun 2000 10:27:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17845; Fri, 16 Jun 2000 13:27:26 -0400 (EDT) Message-Id: <200006161727.NAA17845@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 16 Jun 2000 13:27:26 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the CAST-128 Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 27, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt From owner-ietf-smime Mon Jun 19 13:14:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA26520 for ietf-smime-bks; Mon, 19 Jun 2000 13:14:45 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26516 for ; Mon, 19 Jun 2000 13:14:44 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 19 Jun 2000 13:14:15 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 13:14:14 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C594FF86@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Date: Mon, 19 Jun 2000 13:14:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 1550A09D54874-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Two comments, don't know if they're major. 1. Section 3 does not list an SMIMECapability for key wrapping using IDEA, only for symmetric encryption. Don't know if that was intended. 2. I think that the example in section 3 should clarify that the cast5CBCParameters are encoded with the iv omitted. Blake -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Friday, June 16, 2000 10:27 AM Cc: ietf-smime@imc.org Subject: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the CAST-128 Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 27, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt From owner-ietf-smime Tue Jun 20 07:20:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07989 for ietf-smime-bks; Tue, 20 Jun 2000 07:20:02 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07982 for ; Tue, 20 Jun 2000 07:20:01 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 10:19:35 -0400 Message-ID: From: Carlisle Adams To: "'Blake Ramsdell'" Cc: "'ietf-smime@imc.org'" Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Date: Tue, 20 Jun 2000 10:19:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Blake, Good to hear from you again! > ---------- > From: Blake Ramsdell[SMTP:blake.ramsdell@tumbleweed.com] > Sent: Monday, June 19, 2000 4:14 PM > To: 'ietf-smime@imc.org' > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in > CMS to Proposed Standard > > Two comments, don't know if they're major. > > 1. Section 3 does not list an SMIMECapability for key wrapping using IDEA, > only for symmetric encryption. Don't know if that was intended. I suspect that you mean "CAST-128" above, rather than "IDEA"... In any case, I originally had both OIDs here (symm. encryption and key wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the following comment: "2. Section 3 Para 1. You state that you must include the above OIDs in the symmetric algorithms section of capabilities, but only one of the oids is a symmetric algorithm. At the current time we are "implying" the key wrap from the symmetric algorithm as only same key wrap is supported in CMS. Please change to the correct OID reference." So, I took out the key wrap OID and left only the one for symmetric encryption. > 2. I think that the example in section 3 should clarify that the > cast5CBCParameters are encoded with the iv omitted. I guess it seemed clear to me that if you were only advertising your capabilities (in this case, symmetric algorithm and key length), an IV would be irrelevant and would therefore be omitted. If you wish, however, I can add a sentence to this effect when the document has been approved and I get the 1-day window to send any tiny edits to the RFC editor. Let me know if you really think this is necessary. Thanks for taking the time to look through this draft! Carlisle. From owner-ietf-smime Tue Jun 20 08:03:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09870 for ietf-smime-bks; Tue, 20 Jun 2000 08:03:42 -0700 (PDT) Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09864 for ; Tue, 20 Jun 2000 08:03:40 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 11:04:20 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C035@panda.chrysalis-its.com> To: pgut001@cs.aucKland.ac.nz Cc: ietf-smime@imc.org Subject: CMS Compressed Data Content Type Date: Tue, 20 Jun 2000 11:04:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDAC8.CF7D23E4" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDAC8.CF7D23E4 Content-Type: text/plain; charset="iso-8859-1" Peter, Do you plan to update your Internet Draft on the S/MIME compressed data content type, which expired on April 2000? I would much prefer having a standard and interoperable way of compressing data before performing encryption than having a different proprietary approach from each vendor. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDAC8.CF7D23E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CMS Compressed Data Content Type

Peter,

Do you plan to update your Internet Draft on the = S/MIME compressed data content type, which expired on April = 2000?

I would much prefer having a standard and = interoperable way of compressing data before performing encryption than = having a different proprietary approach from each vendor.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFDAC8.CF7D23E4-- From owner-ietf-smime Tue Jun 20 10:52:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20541 for ietf-smime-bks; Tue, 20 Jun 2000 10:52:49 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20535 for ; Tue, 20 Jun 2000 10:52:48 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA18495 for ; Tue, 20 Jun 2000 10:52:21 -0700 (PDT) Message-Id: <4.2.0.58.20000620132351.00ae5d10@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 20 Jun 2000 13:25:43 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Agenda Topics Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: WG Members: I am starting to put together the agenda for the IETF meeting in July. If you would like a time slot in the two hour meeting, please send me e-mail. Please reply to this note, but do not copy the whole list. Thanks, Russ From owner-ietf-smime Wed Jun 21 09:30:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22389 for ietf-smime-bks; Wed, 21 Jun 2000 09:30:44 -0700 (PDT) Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22375 for ; Wed, 21 Jun 2000 09:30:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 21 Jun 2000 09:30:33 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: New patent claim Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Someone is claiming a patent on parts of S/MIME. See . --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Jun 21 10:16:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26558 for ietf-smime-bks; Wed, 21 Jun 2000 10:16:22 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26551; Wed, 21 Jun 2000 10:16:20 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.1/8.10.1) with ESMTP id e5LHFpg50665; Wed, 21 Jun 2000 10:15:51 -0700 (PDT) Message-ID: <3950F847.84A0C2C@software-munitions.com> Date: Wed, 21 Jun 2000 10:15:51 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: New patent claim References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman / IMC wrote: > > Someone is claiming a patent on parts of S/MIME. See > . > I recognize the domain ex-pressnet.com. I was just spammed by them. Perhaps that is an indication of their business model? From owner-ietf-smime Wed Jun 21 15:59:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02344 for ietf-smime-bks; Wed, 21 Jun 2000 15:59:50 -0700 (PDT) Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02338; Wed, 21 Jun 2000 15:59:49 -0700 (PDT) Received: from bgg1.directory-applications.com (goldengate-bridge.veritas.com [63.197.92.2]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with ESMTP id e5LN00623043; Wed, 21 Jun 2000 16:00:00 -0700 (PDT) Message-Id: <4.3.1.0.20000621155925.00acfd60@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 21 Jun 2000 16:01:22 -0700 To: Paul Hoffman / IMC , ietf-smime@imc.org From: Bruce Greenblatt Subject: Re: New patent claim In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:30 AM 06/21/2000 -0700, Paul Hoffman / IMC wrote: >Someone is claiming a patent on parts of S/MIME. See >. > >--Paul Hoffman, Director >--Internet Mail Consortium IBM's patent server says (http://patent.womplex.ibm.com/details?&pn=US05126728__): What is claimed is: 1. A data processing security device comprising: a) memory means for storing a plurality of authorized field protection introducer codes, b) means for evaluating a stream of data flowing from a source of character codes to identify field protection introducer codes within the stream of data, said means for evaluating being in communication with said memory means, said evaluating means comprising comparison means for comparing introducer codes within the stream of data to said authorized codes in said memory means, and c) means for replacing data after said field introducer codes within said stream of data with replacement characters if the field introducer codes within the stream of data do not match at least one of said authorized codes stored in said memory means, said means for replacing being in communication with said evaluating means. This doesn't seem like it applies to me. I know that message security labels have been around forever (at least as far back as X.400 1988) in the email world. It is also very hardware oriented... Bruce From owner-ietf-smime Thu Jun 22 05:27:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10351 for ietf-smime-bks; Thu, 22 Jun 2000 05:27:28 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10347 for ; Thu, 22 Jun 2000 05:27:26 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27600; Thu, 22 Jun 2000 08:27:40 -0400 (EDT) Message-Id: <200006221227.IAA27600@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-01.txt Date: Thu, 22 Jun 2000 08:27:40 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the RSAES-OAEP Transport Algorithm in CMS Author(s) : R. Housley Filename : draft-ietf-smime-cms-rsaes-oaep-01.txt Pages : 8 Date : 21-Jun-00 This document describes the use of the RSAES-OAEP key transport method of key management within the Cryptographic Message Syntax [CMS]. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cms-rsaes-oaep-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000621091902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsaes-oaep-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000621091902.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Jun 22 07:49:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA14538 for ietf-smime-bks; Thu, 22 Jun 2000 07:49:15 -0700 (PDT) Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14531; Thu, 22 Jun 2000 07:49:14 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA07841; Thu, 22 Jun 2000 07:46:59 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 07:48:23 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB6A@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Bruce Greenblatt'" , Paul Hoffman / IMC , ietf-smime@imc.org Subject: RE: New patent claim Date: Thu, 22 Jun 2000 07:48:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFDC37.89A2C0C0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BFDC37.89A2C0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I also read the claims. I cannot see the connection. What did come to mind as a possibility was that some lawyer persuaded his client that he had to file the notice (and charged him a couple of hundred bucks for doing so). Phill ------=_NextPart_000_0000_01BFDC37.89A2C0C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMjE0NDkyN1owIwYJKoZI hvcNAQkEMRYEFL6z+xKRPcemL97fLjv0fcedyt0sMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAptImX6Lw/ag0m8xF8xToazZqDTQl0JK6F1GWQwSO8eoc8ynqdq8wSYxZHpJzbPi3 +PB2lWd8yWG68mi6iQZypQQrGTLpLYvrEdIQ7vAXicf0+84cauGlMaBi8etb0VNdMvpxB+l6hyye EPSba/Q5jnIi8hfamKz+HDXUyq/j4D8AAAAAAAA= ------=_NextPart_000_0000_01BFDC37.89A2C0C0-- From owner-ietf-smime Thu Jun 22 09:11:44 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18365 for ietf-smime-bks; Thu, 22 Jun 2000 09:11:44 -0700 (PDT) Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18359 for ; Thu, 22 Jun 2000 09:11:43 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 12:12:44 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C048@panda.chrysalis-its.com> To: ietf-smime@imc.org Cc: pgut001@cs.aucKland.ac.nz Subject: RE: CMS Compressed Data Content Type Date: Thu, 22 Jun 2000 12:12:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC64.B1FC98E8" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDC64.B1FC98E8 Content-Type: text/plain; charset="iso-8859-1" Russ, I understand from the Final 29 March 2000 S/MIME WG Minutes that you mentioned about the issue of a MIME compress data type that Jeff Schiller recommended that the S/MIME WG "just do it" because the issue needs to be resolved for efficiency purposes. There are currently two other Internet Draft were this same issue of a MIME compress data type has been brought up: a. The Internet Draft "draft-ietf-ediint-as1-11.txt" about MIME-based Secure EDI from the Electronic Data Interchange Internet Integration (EDIINT) WG also has a requirement for a MIME compress data type, but mentions the following in Section 5.4.1: "Applying compression before encryption strengthens cryptographic security since repetitious strings are reduced. This sequence of signature, compression, then encryption, or compression then encryption, is consistent with the order in which PGP implementations handle compression. Note: Compression is done automatically when using PGP encryption. The MIME standards do not define a way in which to convey that a message has been compressed. However, RFC2045 does allow the definition of additional MIME header fields to further describe the content of a message. RFC2068, the HTTP/1.1 specification does define a Content-Encoding field that is primarily used to convey compression information: Content-Encoding = "Content-Encoding" ":" content-coding where content-coding can take on the values of "gzip" or "compress". The gzip compression standard is further described in RFC 1952, and compress is the standard UNIX file compression program. Both gzip and compress are registered with IANA." b. The Internet Draft "draft-ietf-avt-rtp-mime-02.txt" about MIME Type Registration of Real-time Transport Protocol (RTP) Payload Formats from the Audio/Video Transport (AVT) WG on the other hand is using MIME registration procedure described in RFC2048 to register MIME subtype names for use with the RTP [RFC1889], including various data compression formats for audio and video. Should not the S/MIME WG just do it and create a standard interoperable MIME compress data type as proposed by Peter, which could be used by both the S/MIME WG and the EDIINT WG? Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: FRousseau@chrysalis-its.com [mailto:FRousseau@chrysalis-its.com] Sent: Tuesday, June 20, 2000 11:04 AM To: pgut001@cs.aucKland.ac.nz Cc: ietf-smime@imc.org Subject: CMS Compressed Data Content Type Peter, Do you plan to update your Internet Draft on the S/MIME compressed data content type, which expired on April 2000? I would much prefer having a standard and interoperable way of compressing data before performing encryption than having a different proprietary approach from each vendor. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDC64.B1FC98E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CMS Compressed Data Content Type

Russ,

I understand from the Final 29 March 2000 S/MIME WG = Minutes that you mentioned about the issue of a MIME compress data type = that Jeff Schiller recommended that the S/MIME WG "just do = it" because the issue needs to be resolved for efficiency = purposes.

There are currently two other Internet Draft were = this same issue of a MIME compress data type has been brought = up:

a. The Internet Draft = "draft-ietf-ediint-as1-11.txt" about MIME-based Secure EDI = from the Electronic Data Interchange Internet Integration (EDIINT) WG = also has a requirement for a MIME compress data type, but mentions the = following in Section 5.4.1:

"Applying compression before encryption = strengthens cryptographic security since repetitious strings are = reduced. This sequence of signature, compression, then encryption, or = compression then encryption, is consistent with the order in which PGP = implementations handle = compression.          =  

      
Note: Compression is done automatically when using = PGP encryption.

The MIME standards do not define a way in which to = convey that a message has been compressed. However, RFC2045 does allow = the definition of additional MIME header fields to further describe the = content of a message.

RFC2068, the HTTP/1.1 specification does define a = Content-Encoding field that is primarily used to convey compression = information:

 
        = Content-Encoding =3D "Content-Encoding" ":" = content-coding

where content-coding can take on the values of = "gzip" or "compress". The gzip compression standard = is further described in RFC 1952, and compress is the standard UNIX = file compression program. Both gzip and compress are registered with = IANA."

b. The Internet Draft = "draft-ietf-avt-rtp-mime-02.txt" about MIME Type Registration = of Real-time Transport Protocol (RTP) Payload Formats from the = Audio/Video Transport (AVT) WG on the other hand is using MIME = registration procedure described in RFC2048 to register MIME subtype = names for use with the RTP [RFC1889], including various data = compression formats for audio and video.

Should not the S/MIME WG just do it and create a = standard interoperable MIME compress data type as proposed by Peter, = which could be used by both the S/MIME WG and the EDIINT WG?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: FRousseau@chrysalis-its.com [mailto:FRousseau@chrysalis-i= ts.com]
Sent: Tuesday, June 20, 2000 11:04 AM
To: pgut001@cs.aucKland.ac.nz
Cc: ietf-smime@imc.org
Subject: CMS Compressed Data Content Type


Peter,

Do you plan to update your Internet Draft on the = S/MIME compressed data content type, which expired on April = 2000?

I would much prefer having a standard and = interoperable way of compressing data before performing encryption than = having a different proprietary approach from each vendor.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFDC64.B1FC98E8-- From owner-ietf-smime Fri Jun 23 07:00:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15406 for ietf-smime-bks; Fri, 23 Jun 2000 07:00:57 -0700 (PDT) Received: from ns1.futurelink.net ([207.229.55.254]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA15395; Fri, 23 Jun 2000 07:00:55 -0700 (PDT) From: MMcClennan@jawstech.com Received: from mail.jawstech.com by ns1.futurelink.net via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Jun 2000 14:01:15 UT Subject: RE: New patent claim To: Philip Hallam-Baker Cc: bgreenblatt@directory-applications.com, ietf-smime@imc.org, owner-ietf-smime@mail.imc.org, phoffman@imc.org X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Fri, 23 Jun 2000 09:41:29 -0400 X-MIMETrack: Serialize by Router on jawnotes1/Jawstech(Release 5.0.2c |February 2, 2000) at 06/23/2000 07:56:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Et all, While I agree with Phil that the claims do not seem connected. I wonder if the S/MIME group has access to a legal staff and could ask the question? Mike McClennan Director of Marketing - Secure Messaging Tel: (416) 418-1144 ---------------------------------------------------------------------------------- Keep your data safe! Encryption for your email. Click here: http://www.jawstech.com/store Philip Hallam-Baker , Paul Sent by: Hoffman / IMC , owner-ietf-smime@ma ietf-smime@imc.org il.imc.org cc: Subject: RE: New patent claim 06/22/00 10:48 AM I also read the claims. I cannot see the connection. What did come to mind as a possibility was that some lawyer persuaded his client that he had to file the notice (and charged him a couple of hundred bucks for doing so). Phill From owner-ietf-smime Fri Jun 23 09:52:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23021 for ietf-smime-bks; Fri, 23 Jun 2000 09:52:27 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23015 for ; Fri, 23 Jun 2000 09:52:25 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Jun 2000 10:52:11 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 23 Jun 2000 10:52:01 -0600 From: "Bob Jueneman" To: , Cc: , , Subject: Re: Last Call: Use of the CAST-128 Encryption Algorithm in CMS toProposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23017 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will raise the same objection that I raised within the S/MIME working group. I have nothing against the CAST-128 algorithm per se, or against proprietary algorithms in general, but I am strongly opposed to including more and more algorithms within the S/MIME suite that really don't provide any significant or measurable improvement in security when compared to existing choices. The fact that such algorithms are considered "standard", even if they are optional, inevitably leads to competitive pressure to include those algorithms within e-mail packages, as well as cryptographic toolkits. The inclusion in the cryptographic infrastructure then tends to proliferate to other programs and applications as well. This leads to greatly increased development, test, and documentation costs within the vendor community, as well as to code bloat and interoperability headaches, but with no significant benefit to the users. I see absolutely no reason to include CAST, IDEA, or some of the other algorithms that have recently been proposed, when AES is about to come out. I would encourage the IESG to "just say no" to the "let 10,000 standards bloom" type of mentality, and to make the necessary hard choices. I believe that this should be an informational RFC, and not a Proposed Standard. Sincerely, Bob Robert R. Jueneman Security Architect Novell, Inc. 1800 South novell Place Provo, Utah 80606 801/861-7387 >>> iesg-secretary@ietf.org 06/16/00 11:27AM >>> The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the CAST-128 Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 27, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt From owner-ietf-smime Fri Jun 23 12:17:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA26980 for ietf-smime-bks; Fri, 23 Jun 2000 12:17:04 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26917; Fri, 23 Jun 2000 12:17:00 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA26250; Fri, 23 Jun 2000 12:17:18 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 12:16:04 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB76@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'MMcClennan@jawstech.com'" , Philip Hallam-Baker Cc: bgreenblatt@directory-applications.com, ietf-smime@imc.org, owner-ietf-smime@mail.imc.org, phoffman@imc.org Subject: RE: New patent claim Date: Fri, 23 Jun 2000 12:16:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0020_01BFDD26.1891B040"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0020_01BFDD26.1891B040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The working group does not have any budget for any purpose (as far as I am aware). Obtaining a non-infringement opinion on even the most ridiculous claim costs may tens of thousands of dollars in legal time and at least as much in engineer time - if you can find one prepared to spend that much time talking to lawyers. Under UK law there is actually a tort of demanding monies based on a bogus intellectual property claim. I'd rather apply to the US patent office for a patent on some critical biological function which according to the USPTO motto 'ask and ye shall receive' would inevitably be granted. Then if anyone ever sued we could file a cross claim and demand an injunction demanding that they cease the bodily functions concerned pending the outcome of the case. Phill -----Original Message----- From: MMcClennan@jawstech.com [mailto:MMcClennan@jawstech.com] Sent: Friday, June 23, 2000 9:41 AM To: Philip Hallam-Baker Cc: bgreenblatt@directory-applications.com; ietf-smime@imc.org; owner-ietf-smime@mail.imc.org; phoffman@imc.org Subject: RE: New patent claim Et all, While I agree with Phil that the claims do not seem connected. I wonder if the S/MIME group has access to a legal staff and could ask the question? Mike McClennan Director of Marketing - Secure Messaging Tel: (416) 418-1144 ------------------------------------------------------------------------ ---------- Keep your data safe! Encryption for your email. Click here: http://www.jawstech.com/store Philip Hallam-Baker , Paul Sent by: Hoffman / IMC , owner-ietf-smime@ma ietf-smime@imc.org il.imc.org cc: Subject: RE: New patent claim 06/22/00 10:48 AM I also read the claims. I cannot see the connection. What did come to mind as a possibility was that some lawyer persuaded his client that he had to file the notice (and charged him a couple of hundred bucks for doing so). Phill ------=_NextPart_000_0020_01BFDD26.1891B040 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzE5MTcwOFowIwYJKoZI hvcNAQkEMRYEFHViAmORUoBVEllvWaQt8U0HJ5uPMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGANYjzGs3G1E+z+QndpeVqsi03XK9roWNAHLmHG+JftStA5zvkdr93EpaAMfxMlgP3 gRny/OJsnz/WoN97CEx5g5OJBVDqu7j/mMZkKdIeHsOMnAxk+bEXLuZRsuu/OLRQ+HfUo7h/fUGv lr/NO5Dtqs45RbhW2pL1Su6NeBIDKXsAAAAAAAA= ------=_NextPart_000_0020_01BFDD26.1891B040-- From owner-ietf-smime Fri Jun 23 12:35:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00870 for ietf-smime-bks; Fri, 23 Jun 2000 12:35:44 -0700 (PDT) Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00859; Fri, 23 Jun 2000 12:35:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EB76@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F408EB76@vhqpostal.verisign.com> Date: Fri, 23 Jun 2000 12:35:29 -0700 To: Philip Hallam-Baker , "'MMcClennan@jawstech.com'" From: Paul Hoffman / IMC Subject: RE: New patent claim Cc: bgreenblatt@directory-applications.com, ietf-smime@imc.org, owner-ietf-smime@mail.imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:16 PM -0700 6/23/00, Philip Hallam-Baker wrote: >The working group does not have any budget for any purpose (as far as >I am aware). For those of you not familiar with Phill's dry Brit humor (surely he writes for NTK?), the IETF does not spend money researching laws. It never has. In fact, they did not research whether or not they should have posted the IPR statement that started this thread: they just did it blindly, as they do with all the rest of them. It is up to you to decide whether or not the patent is valid, applies to anything you are doing, and so on. (And, before someone posts a "why not" type response, might I remind you that you all paid no money to be members of the IETF? That might give you a clue....) --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri Jun 23 13:15:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02880 for ietf-smime-bks; Fri, 23 Jun 2000 13:15:01 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA02861 for ; Fri, 23 Jun 2000 13:14:57 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Fri, 23 Jun 2000 13:14:48 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:14:48 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5950011@mail.deming.com> From: "Blake Ramsdell" To: "'jimsch@nwlink.com'" , "Carlisle Adams" cc: ietf-smime@imc.org Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Date: Fri, 23 Jun 2000 13:14:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 154D1AB216093-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So what's the difference between the CAST draft and the IDEA draft, then? The IDEA draft specifies it, doesn't it? Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, June 23, 2000 1:10 PM To: Carlisle Adams; Blake Ramsdell Cc: ietf-smime@imc.org Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard This is still my position. If, for a D-H key, you make the statment that CAST128 is supported as a bulk algorithm, then you must support the CAST128 wrap of CAST128 because that is the only way of doing it. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Carlisle Adams > Sent: Tuesday, June 20, 2000 7:19 AM > To: 'Blake Ramsdell' > Cc: 'ietf-smime@imc.org' > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS > to Proposed Standard > > > Hi Blake, > > Good to hear from you again! > > > ---------- > > From: Blake Ramsdell[SMTP:blake.ramsdell@tumbleweed.com] > > Sent: Monday, June 19, 2000 4:14 PM > > To: 'ietf-smime@imc.org' > > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in > > CMS to Proposed Standard > > > > Two comments, don't know if they're major. > > > > 1. Section 3 does not list an SMIMECapability for key wrapping > using IDEA, > > only for symmetric encryption. Don't know if that was intended. > > I suspect that you mean "CAST-128" above, rather than "IDEA"... > > In any case, I originally had both OIDs here (symm. encryption and key > wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the > following comment: > > "2. Section 3 Para 1. You state that you must include the above OIDs in > the symmetric algorithms section of capabilities, but only one of the oids > is a symmetric algorithm. At the > current time we are "implying" the key wrap from the symmetric > algorithm as > only same key wrap is supported in CMS. Please change to the correct OID > reference." > > So, I took out the key wrap OID and left only the one for symmetric > encryption. > > > 2. I think that the example in section 3 should clarify that the > > cast5CBCParameters are encoded with the iv omitted. > > I guess it seemed clear to me that if you were only advertising your > capabilities (in this case, symmetric algorithm and key length), > an IV would > be irrelevant and would therefore be omitted. If you wish, however, I can > add a sentence to this effect when the document has been approved > and I get > the 1-day window to send any tiny edits to the RFC editor. Let me know if > you really think this is necessary. > > Thanks for taking the time to look through this draft! > > Carlisle. > > From owner-ietf-smime Fri Jun 23 13:09:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02025 for ietf-smime-bks; Fri, 23 Jun 2000 13:09:12 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02021 for ; Fri, 23 Jun 2000 13:09:11 -0700 (PDT) Received: from jimsch1t (ip162.du1.bel.nwlink.com [209.20.136.162]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id NAA03731; Fri, 23 Jun 2000 13:09:28 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "Carlisle Adams" , "'Blake Ramsdell'" Cc: Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Date: Fri, 23 Jun 2000 13:09:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is still my position. If, for a D-H key, you make the statment that CAST128 is supported as a bulk algorithm, then you must support the CAST128 wrap of CAST128 because that is the only way of doing it. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Carlisle Adams > Sent: Tuesday, June 20, 2000 7:19 AM > To: 'Blake Ramsdell' > Cc: 'ietf-smime@imc.org' > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS > to Proposed Standard > > > Hi Blake, > > Good to hear from you again! > > > ---------- > > From: Blake Ramsdell[SMTP:blake.ramsdell@tumbleweed.com] > > Sent: Monday, June 19, 2000 4:14 PM > > To: 'ietf-smime@imc.org' > > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in > > CMS to Proposed Standard > > > > Two comments, don't know if they're major. > > > > 1. Section 3 does not list an SMIMECapability for key wrapping > using IDEA, > > only for symmetric encryption. Don't know if that was intended. > > I suspect that you mean "CAST-128" above, rather than "IDEA"... > > In any case, I originally had both OIDs here (symm. encryption and key > wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the > following comment: > > "2. Section 3 Para 1. You state that you must include the above OIDs in > the symmetric algorithms section of capabilities, but only one of the oids > is a symmetric algorithm. At the > current time we are "implying" the key wrap from the symmetric > algorithm as > only same key wrap is supported in CMS. Please change to the correct OID > reference." > > So, I took out the key wrap OID and left only the one for symmetric > encryption. > > > 2. I think that the example in section 3 should clarify that the > > cast5CBCParameters are encoded with the iv omitted. > > I guess it seemed clear to me that if you were only advertising your > capabilities (in this case, symmetric algorithm and key length), > an IV would > be irrelevant and would therefore be omitted. If you wish, however, I can > add a sentence to this effect when the document has been approved > and I get > the 1-day window to send any tiny edits to the RFC editor. Let me know if > you really think this is necessary. > > Thanks for taking the time to look through this draft! > > Carlisle. > > From owner-ietf-smime Fri Jun 23 14:38:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA06739 for ietf-smime-bks; Fri, 23 Jun 2000 14:38:56 -0700 (PDT) Received: from citicorp.com (mango1-a.citicorp.com [192.193.196.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06731 for ; Fri, 23 Jun 2000 14:38:54 -0700 (PDT) From: bartley.omalley@citicorp.com Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.196.186]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id RAA16043 for ; Fri, 23 Jun 2000 17:33:09 -0400 (EDT) Received: from x400prod2.cgin.us-md.citicorp.com (omroute4lan1.email.citicorp.com [163.39.249.74]) by myrtle1.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id JAA16935 for ; Fri, 23 Jun 2000 09:21:22 -0400 (EDT) Received: from mercury.lew.gb.citicorp.com (mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id JAA07921 for ; Fri, 23 Jun 2000 09:22:19 -0400 (EDT) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA28946 for ietf-smime@imc.org; Fri, 23 Jun 2000 13:05:38 +0100 (BST) X-OpenMail-Hops: 1 Date: Fri, 23 Jun 2000 13:05:25 +0100 Message-Id: Subject: Canonicalisation of embedded MIME objects MIME-Version: 1.0 TO: ietf-smime@imc.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have noticed that a number of files as produced by different mail programs do not seem to be performing canonicalisation of inner objects correctly. The inner objects use LF for line termination not CRLF pairs. It is my understanding that breaks MIME rules for canonicalising embedded objects. To illustrate the problem I enclose a signed-then-encrypted message I have received:(I have removed the routing information) The outer message appears as follows(All lines are terminated with pairs.). ----------------------------------------------------------- Content-Type: application/pkcs7-mime; smime-type=encrypted-data; name="xxx.p7m" Content-Disposition: attachment; filename=xxx.p7m Content-Transfer-Encoding: base64 Message-ID: 19991015:080159:REF12345 MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1UEBhMCVVMx ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW50IDICBDUa : : VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC4RdXrwyH2l 1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WYEo+aKglqhJ -------------------------------------------------------------------------------- ---- The embedded message looks as follows(All lines are terminated with ). ---------------------------------------------------------------------------- Content-Type: application/pkcs7-mime; smime-type=signed-data; name="xxx.p7m" Content-Disposition: attachment; filename=xxx.p7m Content-Transfer-Encoding: base64 Message-ID: 19990225:131734:20499 MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKoZIhvcNAQcB : : mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSlvuG6deAhgZ XJ0KskSW4qT5 ----------------------------------------------------------------------------- The inner application file looks as follows: With Content lines terminated with and the data segment with no line ends. ---------------------------------------------------------------------------- Content-Type: application/EDIFACT; name="xxx.edi" Content-Transfer-Encoding: binary UNA:+.? 'UNB+UNOA:1+ ----------------------------------------------------------------------------- It is my interpretation that the use of to terminate the Content headers in the latter two messages above is not valid. Can someone provide me with a definitive answer. Thanks, Bartley. From owner-ietf-smime Sat Jun 24 18:13:08 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA07485 for ietf-smime-bks; Sat, 24 Jun 2000 18:13:08 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07479 for ; Sat, 24 Jun 2000 18:13:07 -0700 (PDT) Received: from jimsch1t (ip164.du1.bel.nwlink.com [209.20.136.164]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id SAA25522; Sat, 24 Jun 2000 18:13:32 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Date: Sat, 24 Jun 2000 18:13:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It would be called that I missed that issue on the IDEA draft since I was still fixated over the fact that the encodings in the draft was wrong and had not looked at the higher level. Additionally, since I reviewed them at different times, I did not have the same critiera all of the time. (I suppose I should write it down so that I am more consistant :) jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Jim Schaad > Sent: Friday, June 23, 2000 1:10 PM > To: Carlisle Adams; 'Blake Ramsdell' > Cc: ietf-smime@imc.org > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS > to Proposed Standard > > > This is still my position. If, for a D-H key, you make the statment that > CAST128 is supported as a bulk algorithm, then you must support > the CAST128 > wrap of CAST128 because that is the only way of doing it. > > jim > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Carlisle Adams > > Sent: Tuesday, June 20, 2000 7:19 AM > > To: 'Blake Ramsdell' > > Cc: 'ietf-smime@imc.org' > > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS > > to Proposed Standard > > > > > > Hi Blake, > > > > Good to hear from you again! > > > > > ---------- > > > From: Blake Ramsdell[SMTP:blake.ramsdell@tumbleweed.com] > > > Sent: Monday, June 19, 2000 4:14 PM > > > To: 'ietf-smime@imc.org' > > > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in > > > CMS to Proposed Standard > > > > > > Two comments, don't know if they're major. > > > > > > 1. Section 3 does not list an SMIMECapability for key wrapping > > using IDEA, > > > only for symmetric encryption. Don't know if that was intended. > > > > I suspect that you mean "CAST-128" above, rather than "IDEA"... > > > > In any case, I originally had both OIDs here (symm. encryption and key > > wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad > included the > > following comment: > > > > "2. Section 3 Para 1. You state that you must include the > above OIDs in > > the symmetric algorithms section of capabilities, but only one > of the oids > > is a symmetric algorithm. At the > > current time we are "implying" the key wrap from the symmetric > > algorithm as > > only same key wrap is supported in CMS. Please change to the > correct OID > > reference." > > > > So, I took out the key wrap OID and left only the one for symmetric > > encryption. > > > > > 2. I think that the example in section 3 should clarify that the > > > cast5CBCParameters are encoded with the iv omitted. > > > > I guess it seemed clear to me that if you were only advertising your > > capabilities (in this case, symmetric algorithm and key length), > > an IV would > > be irrelevant and would therefore be omitted. If you wish, > however, I can > > add a sentence to this effect when the document has been approved > > and I get > > the 1-day window to send any tiny edits to the RFC editor. Let > me know if > > you really think this is necessary. > > > > Thanks for taking the time to look through this draft! > > > > Carlisle. > > > > > > From owner-ietf-smime Mon Jun 26 09:07:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14799 for ietf-smime-bks; Mon, 26 Jun 2000 09:07:25 -0700 (PDT) Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14793; Mon, 26 Jun 2000 09:07:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20000626180029.A14040@informatik.uni-hamburg.de> References: <20000626180029.A14040@informatik.uni-hamburg.de> Date: Mon, 26 Jun 2000 09:07:57 -0700 To: Gunnar Kedenburg <9kedenbu@informatik.uni-hamburg.de>, ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: SFL 1.6 on Linux compile problems Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is the wrong mailing list for your question. Please send SFL questions to the imc-sfl@imc.org mailing list. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Mon Jun 26 08:59:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14342 for ietf-smime-bks; Mon, 26 Jun 2000 08:59:59 -0700 (PDT) Received: from rzdspc1.informatik.uni-hamburg.de (root@rzdspc1.informatik.uni-hamburg.de [134.100.9.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14338 for ; Mon, 26 Jun 2000 08:59:56 -0700 (PDT) Received: from rzdspc3.informatik.uni-hamburg.de (9kedenbu@rzdspc3.informatik.uni-hamburg.de [134.100.8.63]) by rzdspc1.informatik.uni-hamburg.de (8.10.1/8.10.1) with ESMTP id e5QG0Ub29464 for ; Mon, 26 Jun 2000 18:00:30 +0200 (MET DST) Received: (from 9kedenbu@localhost) by rzdspc3.informatik.uni-hamburg.de (8.10.1/8.10.1) id e5QG0UL14282 for ietf-smime@imc.org; Mon, 26 Jun 2000 18:00:30 +0200 (MET DST) Date: Mon, 26 Jun 2000 18:00:29 +0200 From: Gunnar Kedenburg <9kedenbu@informatik.uni-hamburg.de> To: ietf-smime@imc.org Subject: SFL 1.6 on Linux compile problems Message-ID: <20000626180029.A14040@informatik.uni-hamburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello! I am experiencing quite some problems compiling SFL 1.6 on Linux. First thing is that the distribution ZIP-file did not preserve uppercase letters in filenames. I fixed this for some files, but it would be nice to have a tar-file with the correct filenames. I am also trying to port SFL to an autoconf/automake build procedure, because the current makefile system didn't seem to work for us. Has anybody done such work before, and is able to share his work with me? This would save me quite some time :) Thanks -- Gunnar. From owner-ietf-smime Mon Jun 26 22:44:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13095 for ietf-smime-bks; Mon, 26 Jun 2000 22:44:48 -0700 (PDT) Received: from mh.transparity.com (IDENT:root@[203.127.198.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA13091 for ; Mon, 26 Jun 2000 22:44:45 -0700 (PDT) Received: from transparity.com (xiaoying.secureage.com [203.127.198.231]) by mh.transparity.com (8.9.3/8.8.7) with ESMTP id NAA01858 for ; Tue, 27 Jun 2000 13:51:39 +0800 Message-ID: <39584203.A10ECBA4@transparity.com> Date: Tue, 27 Jun 2000 13:56:19 +0800 From: Wu Xiao Ying Organization: Transparity Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: smime Subject: Re: SFL 1.6 on Linux compile problems References: <20000626180029.A14040@informatik.uni-hamburg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Here I'm trying to implement EnvelopedData KEKRecipientInfo RC2 key wrapping algorithm. But my result is different from the example given in draft-ietf-smime-examples. The problem seemed to be at the RC2 encryption, but my Rc2 implementation has been tested with both IE and Netscape and works fine. So I doubt the example may have some error. Anyone can help? Thanks a lot in advance. Regards, Xiaoying From owner-ietf-smime Tue Jun 27 03:43:38 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA00235 for ietf-smime-bks; Tue, 27 Jun 2000 03:43:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00231 for ; Tue, 27 Jun 2000 03:43:37 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06317; Tue, 27 Jun 2000 06:44:16 -0400 (EDT) Message-Id: <200006271044.GAA06317@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-05.txt Date: Tue, 27 Jun 2000 06:44:15 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-05.txt Pages : 6 Date : 26-Jun-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000626113158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626113158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Jun 27 06:09:11 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07040 for ietf-smime-bks; Tue, 27 Jun 2000 06:09:11 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07034 for ; Tue, 27 Jun 2000 06:09:09 -0700 (PDT) Received: by balinese.baltimore.ie; id OAA10397; Tue, 27 Jun 2000 14:09:48 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010383; Tue, 27 Jun 00 14:09:39 +0100 Received: from irlbdc.irl.emea (irlbdc.baltimore.ie [192.168.20.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA13977 for ; Tue, 27 Jun 2000 14:09:39 +0100 Received: by irlbdc.cdsemea.baltimore.com with Internet Mail Service (5.5.2448.0) id ; Tue, 27 Jun 2000 14:09:34 +0100 Message-ID: <3B46C515DDE2D311A70C005004AFCB701E1B3B@emeairl2.cdsemea.baltimore.com> From: William Whyte To: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-idea-05.txt Date: Tue, 27 Jun 2000 14:11:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What's the difference between this draft and the -04 draft? It doesn't seem that the issues raised on the list have been addressed. Cheers, William From owner-ietf-smime Tue Jun 27 13:02:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25924 for ietf-smime-bks; Tue, 27 Jun 2000 13:02:21 -0700 (PDT) Received: from gem.lightlink.com (root@gem.lightlink.com [205.232.34.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25920 for ; Tue, 27 Jun 2000 13:02:19 -0700 (PDT) Received: from kermit.eloq.com (ith2-7a3.twcny.rr.com [24.24.16.163]) by gem.lightlink.com (8.8.8/8.8.8) with ESMTP id QAA10550 for ; Tue, 27 Jun 2000 16:03:00 -0400 Message-Id: <4.3.1.0.20000627155953.00a79ae0@192.9.200.22> X-Sender: gliu#pop.lightlink.com@192.9.200.22 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 27 Jun 2000 16:10:06 -0700 To: ietf-smime@imc.org From: Guangsheng Liu Subject: MIME Parser needed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Currently, I am developing a email reader. Does any body know there is a MIME parser in the market? Thanks. From owner-ietf-smime Tue Jun 27 21:43:54 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA10452 for ietf-smime-bks; Tue, 27 Jun 2000 21:43:54 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10446 for ; Tue, 27 Jun 2000 21:43:53 -0700 (PDT) Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id VAA25214; Tue, 27 Jun 2000 21:44:29 -0700 (PDT) From: "Jim Schaad" Reply-to: jimsch@nwlink.com To: t.dean@eris.dera.gov.uk;w.ottaway@eris.dera.gov.uk;;; Cc: ietf-smime@imc.org Date: Tue, 27 Jun 2000 21:44:29 +0800 Subject: Comments on draft-ietf-smime-domsec-05.txt Message-id: <395982ad.c3c.0@nwlink.com> X-User-Info: 4.54.168.248 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Should the X.400 on hetrogenous messaging be expanded to X.400/P1 similar to SMTP/MIME 2. Section 1.0 bullet 4: Should be Heterogeneous Message Formats not transports. The problem is if you cannot carry the S/MIME content type not the wrapper on the message. (Microsoft Exchange actually uses X.400 headers with a custom content type for internal replication last time I checked and this did not break signatures on these messages as the MIME structure was carried intact.) 3. Section 1 last paragraph: change to more standard wording on MUST. 4. Section 2.1 formatting problem: "signature(if present)using" goes to "signature (if present) using" 5. Section 2.2 - remove MAY from the last sentence. This is a reason to do the signatures, but is not part of the protocol definition. -- change MAY to could. 6. Section 2.3 - ditto above comment for first sentence. You can do this, but it is not part of the protocol defintion. change MAY to can. 7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data" 8. Section 3.0 bullet 1: This concept bothers me. I think that there may be some programs out there that assume atleast one signature in a signed data object except for cases such as degenerate certs only messages. 9. Section 3.0 bullet 1: A better term for this might be a null (or empty) signature layer. This will difference the concept from the discussions about signing with the NULL signature algorithm. 10. Section 3.0 bullet 2: This not clear about the presence (or absense) of a MIME layer. If MIME layer exists, then I fail to see the need for bullet 1 at all. 11. Section 3.0 Para 1: Simple example of why counter-signature and parallel signatures do or don't work for this might be called for. 12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad - review-authority" is legal (difference between 'in' and 'as'. Additionally you might want to do capitalization here as utf8 strings do not do case insensitive name compararisions (i.e. Review-Authority). Also is cn="Jim Schaad" cn="review-authority" legal? [By definition I think that this would only need to be done if the review was on the innermost signature layer. On outer layers I don't believe the intent was that name checking of the certificate and sender should occur otherwise signing MLAs will create lots of havoc.] 13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be explicity forbidden? 14. Section 3.1.1 Last Paragraphy - Please soften last sentence. The correct action should be to flag sender/certificate mismatch not to reject as invalid. 15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a description of generating and processing siganture types. I believe that you meant "All signatures are processed..." 16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using the -- comment syntax of ASN. i.e. id-aa-sigtype-domain-signature :: OBJECT ID {....} -- Domain Signature 17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about originator signature not ecapuslating other signatures -- you are eleminating triple wrapped signature from existance (i.e. S2(E(S1(M))) where S1 and S2 are by the originator. 18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same level have different content in the SigantureType attribute or not? 19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you must remove the mlaExpansion or the first MLA outside will strip the domain signature from the message. 20. Section 3.2 Paragarph 11 - Why is this only a MAY. It would appear that the correct statement is MUST as otherwise the whole process is wasted. 21. Section 3.2 Paragaph ? - Where and how did you get the FROM address in the message. Unless you make a statement about including the SMTP headers at the time of wrapping all you get is the MIME headers which do not include this information. (i.e. this is never going to happen unless you call for it to happen.) 22. Section 3.2 Last Paragraph - Change to make a statement about a single layer as well (or instead of). 23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS? 24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))). S1 has an equivalent label, S2 and S3 both have labels, and the labels are different. Is the equivalent label the same as both labels or only one? 25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST 26. Section 3.3 Paragarph Last - ditto froms ection 3.3 27. Section 3.5 - By default you can have multiple originator signatures (potentially with different algorithms) in a message. So the restriction in this section makes no sense. 28. Section 4 - Where on this table would you put the case of Originator Encrypts to Recipient Domain which encrypts to Receipient? It would appear to be an instance of (a), (b) and (c). 29. Section 4 Paragraphy Last-2 - How can I possibly enforce this? For Key Transport the sender is anonymous, for Key Agreement the senders certificate is often not examined. Additionally the domain component could change so that does match -- or it might be my domain component that did the re-enecryption and would therefore match my domain name and not the senders domain name. 30. General - Please include ASN.1 module at the end with a list of all defined OIDs and structures. Get module oid from Russ. (This request is just pure lazyness on my part but makes some things easier.) 31. General - Do we need to specify the big brother syndrome at this time (encrypt for end-entity and for DCA)? jim schaad http://www.nwlink.com From owner-ietf-smime Wed Jun 28 05:37:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29072 for ietf-smime-bks; Wed, 28 Jun 2000 05:37:00 -0700 (PDT) Received: from exch-bhs-2.redstone.army.mil (exch-bhs-2.redstone.army.mil [136.205.13.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29067 for ; Wed, 28 Jun 2000 05:36:59 -0700 (PDT) Received: by exch-bhs-2.redstone.army.mil with Internet Mail Service (5.5.2448.0) id ; Wed, 28 Jun 2000 07:37:58 -0500 Message-ID: <1345B59AC3C5D211975E00A0C99DAC7A0128E07F@exch-msg-6> From: "Nord, John D Contractor/NCCIM" To: "'Guangsheng Liu'" Cc: ietf-smime@imc.org Subject: RE: MIME Parser needed Date: Wed, 28 Jun 2000 07:37:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Check out MIME++ at http://hunnysoft.com/mimepp/. -----Original Message----- From: Guangsheng Liu [mailto:gliu@eloq.com] Sent: Tuesday, June 27, 2000 6:10 PM To: ietf-smime@imc.org Subject: MIME Parser needed Currently, I am developing a email reader. Does any body know there is a MIME parser in the market? Thanks. From owner-ietf-smime Thu Jun 29 11:25:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26763 for ietf-smime-bks; Thu, 29 Jun 2000 11:25:34 -0700 (PDT) Received: from gem.lightlink.com (root@gem.lightlink.com [205.232.34.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26759 for ; Thu, 29 Jun 2000 11:25:32 -0700 (PDT) Received: from kermit.eloq.com (ith2-7a3.twcny.rr.com [24.24.16.163]) by gem.lightlink.com (8.8.8/8.8.8) with ESMTP id OAA25680 for ; Thu, 29 Jun 2000 14:26:07 -0400 Message-Id: <4.3.1.0.20000629143025.00a7e490@192.9.200.22> X-Sender: gliu#pop.lightlink.com@192.9.200.22 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 29 Jun 2000 14:33:11 -0700 To: ietf-smime@imc.org From: Guangsheng Liu Subject: what is "Content-Disposition" field? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Many thanks for some of you recomending MIME++ parser from http://www.hunnysoft.com/. I have another question, what is the purpose of "Content-Disposition" field, I checked RFC822 and RFC2045-2049, cannot get the answer. Guangsheng Liu From owner-ietf-smime Fri Jun 30 03:41:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00131 for ietf-smime-bks; Fri, 30 Jun 2000 03:41:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00127 for ; Fri, 30 Jun 2000 03:41:54 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12659; Fri, 30 Jun 2000 06:42:46 -0400 (EDT) Message-Id: <200006301042.GAA12659@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-smime@imc.org From: The IESG Subject: Document Action: Use of the IDEA Encryption Algorithm in CMS to Informational Date: Fri, 30 Jun 2000 06:42:46 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Use of the IDEA Encryption Algorithm in CMS' as a Informational RFC. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Note to RFC Editor: Please be sure to insert the IPR text from RFC2026 prior to publication. From owner-ietf-smime Sat Jul 1 13:26:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08429 for ietf-smime-bks; Sat, 1 Jul 2000 13:26:24 -0700 (PDT) Received: from ns01.planet.net.tr (ns01.planet.net.tr [212.174.4.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08422 for ; Sat, 1 Jul 2000 13:25:50 -0700 (PDT) Received: from host (ip233.providence11.ri.pub-ip.psi.net [38.26.242.233]) by ns01.planet.net.tr (8.9.3/8.8.7) with ESMTP id WAA07224; Sat, 1 Jul 2000 22:33:08 +0300 Message-Id: <200007011933.WAA07224@ns01.planet.net.tr> From: "Darren Fern" Subject: Your Chance #220F To: pen39kj@ns01.planet.net.tr X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sat, 01 Jul 2000 07:42:32 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form Dear Candidate,

You were recently selected by The Office of the Managing
Director for a free listing on The International Executive
Who's Who=2E

Our Researchers gather information from many recognized
sources, including professional associations and societies,
trade organizations, newspaper and magazine articles,
professional reference publications, web presence, and
referrals from existing members=2E

As a highly respected professional in your field of
expertise, we believe your contributions merit very
serious consideration for inclusion on The International
Executive Who's Who=2E  To maintain the highest
level of accuracy, we ask you fill out the brief bit of
information below required for inclusion=2E

There is no cost or obligation to be listed on The
International Executive Who's Who=2E
 

My Sincere Thanks,

Lorraine A=2E Michaels
Office Of Managing Director


The International Executive Who's Who is not affiliated or associated with Marquis Who's Who=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E
International Executive Who's Who
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Who's Who=2E For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Who's Who=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of www=2E  Confirmation of its delivery= is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

The International Executive is not affiliated or associated with Marquis Who's Who=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-ietf-smime Sun Jul 2 23:38:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA06538 for ietf-smime-bks; Sun, 2 Jul 2000 23:38:07 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06533 for ; Sun, 2 Jul 2000 23:38:06 -0700 (PDT) Received: from jimsch1t (ip179.du1.bel.nwlink.com [209.20.136.179]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id XAA25631; Sun, 2 Jul 2000 23:39:07 -0700 (PDT) Reply-To: From: "Jim Schaad" To: , Cc: "Ietf-Smime" Subject: Comments on draft-ietf-smime-domsec-05.txt Date: Sun, 2 Jul 2000 23:39:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <4.2.0.58.20000621112157.00959aa0@mail.spyrus.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Should the X.400 on hetrogenous messaging be expanded to X.400/P1 similar to SMTP/MIME 2. Section 1.0 bullet 4: Should be Heterogeneous Message Formats not transports. The problem is if you cannot carry the S/MIME content type not the wrapper on the message. (Microsoft Exchange actually uses X.400 headers with a custom content type for internal replication last time I checked and this did not break signatures on these messages as the MIME structure was carried intact.) 3. Section 1 last paragraph: change to more standard wording on MUST. 4. Section 2.1 formatting problem: "signature(if present)using" goes to "signature (if present) using" 5. Section 2.2 - remove MAY from the last sentence. This is a reason to do the signatures, but is not part of the protocol definition. -- change MAY to could. 6. Section 2.3 - ditto above comment for first sentence. You can do this, but it is not part of the protocol defintion. change MAY to can. 7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data" 8. Section 3.0 bullet 1: This concept bothers me. I think that there may be some programs out there that assume atleast one signature in a signed data object except for cases such as degenerate certs only messages. 9. Section 3.0 bullet 1: A better term for this might be a null (or empty) signature layer. This will difference the concept from the discussions about signing with the NULL signature algorithm. 10. Section 3.0 bullet 2: This not clear about the presence (or absense) of a MIME layer. If MIME layer exists, then I fail to see the need for bullet 1 at all. 11. Section 3.0 Para 1: Simple example of why counter-signature and parallel signatures do or don't work for this might be called for. 12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad - review-authority" is legal (difference between 'in' and 'as'. Additionally you might want to do capitalization here as utf8 strings do not do case insensitive name compararisions (i.e. Review-Authority). Also is cn="Jim Schaad" cn="review-authority" legal? [By definition I think that this would only need to be done if the review was on the innermost signature layer. On outer layers I don't believe the intent was that name checking of the certificate and sender should occur otherwise signing MLAs will create lots of havoc.] 13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be explicity forbidden? 14. Section 3.1.1 Last Paragraphy - Please soften last sentence. The correct action should be to flag sender/certificate mismatch not to reject as invalid. 15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a description of generating and processing siganture types. I believe that you meant "All signatures are processed..." 16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using the -- comment syntax of ASN. i.e. id-aa-sigtype-domain-signature :: OBJECT ID {....} -- Domain Signature 17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about originator signature not ecapuslating other signatures -- you are eleminating triple wrapped signature from existance (i.e. S2(E(S1(M))) where S1 and S2 are by the originator. 18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same level have different content in the SigantureType attribute or not? 19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you must remove the mlaExpansion or the first MLA outside will strip the domain signature from the message. 20. Section 3.2 Paragarph 11 - Why is this only a MAY. It would appear that the correct statement is MUST as otherwise the whole process is wasted. 21. Section 3.2 Paragaph ? - Where and how did you get the FROM address in the message. Unless you make a statement about including the SMTP headers at the time of wrapping all you get is the MIME headers which do not include this information. (i.e. this is never going to happen unless you call for it to happen.) 22. Section 3.2 Last Paragraph - Change to make a statement about a single layer as well (or instead of). 23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS? 24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))). S1 has an equivalent label, S2 and S3 both have labels, and the labels are different. Is the equivalent label the same as both labels or only one? 25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST 26. Section 3.3 Paragarph Last - ditto froms ection 3.3 27. Section 3.5 - By default you can have multiple originator signatures (potentially with different algorithms) in a message. So the restriction in this section makes no sense. 28. Section 4 - Where on this table would you put the case of Originator Encrypts to Recipient Domain which encrypts to Receipient? It would appear to be an instance of (a), (b) and (c). 29. Section 4 Paragraphy Last-2 - How can I possibly enforce this? For Key Transport the sender is anonymous, for Key Agreement the senders certificate is often not examined. Additionally the domain component could change so that does match -- or it might be my domain component that did the re-enecryption and would therefore match my domain name and not the senders domain name. 30. General - Please include ASN.1 module at the end with a list of all defined OIDs and structures. Get module oid from Russ. (This request is just pure lazyness on my part but makes some things easier.) 31. General - Do we need to specify the big brother syndrome at this time (encrypt for end-entity and for DCA)? jim schaad From owner-ietf-smime Mon Jul 3 19:07:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA05578 for ietf-smime-bks; Mon, 3 Jul 2000 19:07:31 -0700 (PDT) Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA05573 for ; Mon, 3 Jul 2000 19:07:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org (Unverified) Message-Id: Date: Mon, 3 Jul 2000 19:08:34 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Fwd: Document Action: Use of the IDEA Encryption Algorithm in CMS to Informational Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings. Due to a mailing list admin blip (discovered by Jim Schaad), this didn't make it to the list. >To: IETF-Announce: ; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-smime@IMC.ORG >From: The IESG >Subject: Document Action: Use of the IDEA Encryption Algorithm in CMS > to Informational >Date: Fri, 30 Jun 2000 06:42:46 -0400 >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the Internet-Draft 'Use of the IDEA Encryption >Algorithm in CMS' as a Informational >RFC. This document is the product of the S/MIME Mail Security Working >Group. The IESG contact persons are Jeffrey Schiller and Marcus >Leech. > > >Note to RFC Editor: > >Please be sure to insert the IPR text from RFC2026 prior to publication. From owner-ietf-smime Tue Jul 4 07:52:51 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA20057 for ietf-smime-bks; Tue, 4 Jul 2000 07:52:51 -0700 (PDT) Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20049 for ; Tue, 4 Jul 2000 07:52:47 -0700 (PDT) Received: (qmail 1894 invoked from network); 4 Jul 2000 14:53:56 -0000 Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 4 Jul 2000 14:53:56 -0000 Received: (qmail 27663 invoked from network); 4 Jul 2000 14:53:55 -0000 Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mailhost.eris.dera.gov.uk with SMTP; 4 Jul 2000 14:53:55 -0000 From: "William Ottaway" To: , Cc: "Ietf-Smime" Subject: RE: Comments on draft-ietf-smime-domsec-05.txt Date: Tue, 4 Jul 2000 15:54:22 +0100 Message-ID: <000a01bfe5c7$bd648f80$110a6280@wottaway.eris.dera.gov.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01BFE5D0.1F28F780" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BFE5D0.1F28F780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Jim, Thanks for your comments. I have responded to each of your comments below. I have also attached a working version of the latest version of DOMSEC that reflects some of the points you have made. Cheers, Bill. > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: 03 July 2000 07:40 > To: t.dean@eris.dera.gov.uk; w.ottaway@eris.dera.gov.uk > Cc: Ietf-Smime > Subject: Comments on draft-ietf-smime-domsec-05.txt > > > 1. Should the X.400 on hetrogenous messaging be expanded to X.400/P1 > similar to SMTP/MIME Its not just P1. Have changed the text to read X.400 series. Is that better? > > 2. Section 1.0 bullet 4: Should be Heterogeneous Message Formats not > transports. The problem is if you cannot carry the S/MIME > content type not > the wrapper on the message. (Microsoft Exchange actually uses > X.400 headers > with a custom content type for internal replication last time I > checked and > this did not break signatures on these messages as the MIME structure was > carried intact.) Done. > > 3. Section 1 last paragraph: change to more standard wording on MUST. Done. > > 4. Section 2.1 formatting problem: "signature(if present)using" goes to > "signature (if present) using" Done. > > 5. Section 2.2 - remove MAY from the last sentence. This is a > reason to do > the signatures, but is not part of the protocol definition. -- > change MAY to > could. Done. > > 6. Section 2.3 - ditto above comment for first sentence. You can do this, > but it is not part of the protocol defintion. change MAY to can. Done. > > 7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data" Done. > > 8. Section 3.0 bullet 1: This concept bothers me. I think that > there may be > some programs out there that assume atleast one signature in a signed data > object except for cases such as degenerate certs only messages. This may be true. However, CMS (section 5.1) states that there may be zero signerInfos. Therefore, the problem is with those programs that expect at least one signature. > > 9. Section 3.0 bullet 1: A better term for this might be a null (or empty) > signature layer. This will difference the concept from the discussions > about signing with the NULL signature algorithm. I did have concerns over this. Have changed it to empty signature layer. > > 10. Section 3.0 bullet 2: This not clear about the presence (or > absense) of > a MIME layer. If MIME layer exists, then I fail to see the need > for bullet > 1 at all. You are going to have to humour me on this point. Can you explain your thoughts in more detail? Points 1 and 2 are there to describe encapsulating an unsigned and a signed message with a domain signature. Are you suggesting that if a MIME layer exists you don't have to specify how to apply a domain signature to an unsigned message? > > 11. Section 3.0 Para 1: Simple example of why counter-signature and > parallel signatures do or don't work for this might be called for. Since we do not mention parallel signatures any more, we only support encapsulation, I believe an example of why counter-signature and parallel signatures do or don't work would be inappropriate and confusing. > > 12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad - > review-authority" is legal (difference between 'in' and 'as'. > Additionally > you might want to do capitalization here as utf8 strings do not do case > insensitive name compararisions (i.e. Review-Authority). Also is cn="Jim > Schaad" cn="review-authority" legal? [By definition I think that > this would > only need to be done if the review was on the innermost signature > layer. On > outer layers I don't believe the intent was that name checking of the > certificate and sender should occur otherwise signing MLAs will > create lots > of havoc.] Good point. Changed 'in' to 'as'. > > 13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be > explicity forbidden? We do not wish to forbid this capability. > > 14. Section 3.1.1 Last Paragraphy - Please soften last sentence. The > correct action should be to flag sender/certificate mismatch not to reject > as invalid. Done. > > 15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a > description of generating and processing siganture types. I believe that > you meant "All signatures are processed..." Your right. Have changed. > > 16. Section 3.1.2 Paragraph ~5 - Please put text in to OID > definition using > the -- comment syntax of ASN. i.e. > id-aa-sigtype-domain-signature :: OBJECT ID {....} > -- Domain Signature Done. > > 17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about > originator signature not ecapuslating other signatures -- you are > eleminating triple wrapped signature from existance (i.e. > S2(E(S1(M))) where > S1 and S2 are by the originator. Good point. Have changed text to allow this. > > 18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same > level have different content in the SigantureType attribute or not? No they can't have different content. Text has now been added to state this. > > 19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you > must remove the mlaExpansion or the first MLA outside will strip > the domain > signature from the message. Removing the mlaExpansion will not stop this in all cases. If there is an envelopedData within the message the MLA will strip off all signatures outside of the envelopedData. Any suggestions as to how to keep the domain signature? > > 20. Section 3.2 Paragarph 11 - Why is this only a MAY. It would > appear that > the correct statement is MUST as otherwise the whole process is wasted. > Where are you referring to? 3.2 para 11 does not contain a MAY. > 21. Section 3.2 Paragaph ? - Where and how did you get the FROM > address in > the message. Unless you make a statement about including the SMTP headers > at the time of wrapping all you get is the MIME headers which do > not include > this information. (i.e. this is never going to happen unless you call for > it to happen.) After reviewing this issue we have decided to remove this text, since even if this field is within the message you can not assume that it contains the identity of the originator. > > 22. Section 3.2 Last Paragraph - Change to make a statement about a single > layer as well (or instead of). Done. > > 23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS? Good catch. Done. > > 24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))). S1 has an equivalent > label, S2 and S3 both have labels, and the labels are different. Is the > equivalent label the same as both labels or only one? This is outside the scope of DOMSEC. I recall this subject being discussed before on the list. Let a sleeping dog lie :-) > > 25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST Done. > > 26. Section 3.3 Paragarph Last - ditto froms ection 3.3 If you are referring to the 'MAY' as in "There MAY be one or more 'domain signature' signatures in an S/MIME encoding" then this should be a MAY and not a MUST. > > 27. Section 3.5 - By default you can have multiple originator signatures > (potentially with different algorithms) in a message. So the > restriction in > this section makes no sense. You are correct. Have removed the restriction. > > 28. Section 4 - Where on this table would you put the case of Originator > Encrypts to Recipient Domain which encrypts to Receipient? It > would appear > to be an instance of (a), (b) and (c). If the originator encrypts to the recipients domain then this is case (b). Then when the recipients domain encrypts to the recipient this is case (c). > > 29. Section 4 Paragraphy Last-2 - How can I possibly enforce > this? For Key > Transport the sender is anonymous, for Key Agreement the senders > certificate > is often not examined. Additionally the domain component could change so > that does match -- or it might be my domain component that did the > re-enecryption and would therefore match my domain name and not > the senders > domain name. The only extra specification to those specified in CMS is that the naming convention and name mapping convention defined in DOMSEC is used. This is specified to locate public keys. For example, if a domain needs to locate the public key for the domain of the recipient w.ottaway@eris.dera.gov.uk then the public key belonging to domain-confidentiality-authority@eris.dera. gov.uk needs to be located, or if not present the public key of an ascendant of the domain name needs to be located. > > 30. General - Please include ASN.1 module at the end with a list of all > defined OIDs and structures. Get module oid from Russ. (This request is > just pure lazyness on my part but makes some things easier.) Done. > > 31. General - Do we need to specify the big brother syndrome at this time > (encrypt for end-entity and for DCA)? Can you foresee any problems if we do? > > jim schaad > ------=_NextPart_000_000B_01BFE5D0.1F28F780 Content-Type: text/plain; name="draft-ietf-smime-domsec-06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-smime-domsec-06.txt" INTERNET-DRAFT T Dean draft-ietf-smime-domsec-06.txt W Ottaway Expires ??/??/?? working version DERA Domain Security Services using S/MIME Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely, for example when two domains use incompatible messaging technologies such as X.400 series and SMTP/MIME, or when a single domain wishes to communicate securely with one of its members residing on an untrusted domain. The scenarios covered by this document are domain to domain, individual to domain and domain to individual communications. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at . Acknowledgements Significant comments were made by Luis Barriga, Greg Colla, Trevor Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev. 1. Introduction The S/MIME [1] series of standards define a data encapsulation format for the provision of a number of security services including data integrity, confidentiality, and authentication. S/MIME is designed for use by messaging clients to deliver security services to distributed messaging applications. There are many circumstances when it is not desirable or practical to provide end-to-end (desktop-to-desktop) security services, particularly between different security domains. An organisation that is considering providing end-to-end security services will typically have to deal with some if not all of the following issues: 1) Heterogeneous message access methods: Users are accessing mail using mechanisms which re-format messages, such as using Web browsers. Message reformatting in the Message Store makes end-to-end encryption and signature validation impossible. 2) Message screening and audit: Server-based mechanisms such as searching for prohibited words or other content, virus scanning, and audit, are incompatible with end-to-end encryption. 3) PKI deployment issues: There may not be any certificate paths between two organisations. Or an organisation may be sensitive about aspects of its PKI and unwilling to expose them to outside access. Also, full PKI deployment for all employees, may be expensive, not necessary or impractical for large organisations. For any of these reasons, direct end-to-end signature validation and encryption are impossible. 4) Heterogeneous message formats: One organisation using X.400 series protocols wishes to communicate with another using SMTP. Message reformatting at gateways makes end-to-end encryption and signature validation impossible. This document describes an approach to solving these problems by providing message security services at the level of a domain or an organisation. This document specifies how these 'domain security services' can be provided using the S/MIME protocol. Domain security services may replace or complement mechanisms at the desktop. For example, a domain may decide to provide desktop-to-desktop signatures but domain-to-domain encryption services. Or it may allow desktop-to- desktop services for intra-domain use, but enforce domain-based services for communication with other domains. Domain services can also be used by individual members of a corporation who are geographically remote and who wish to exchange encrypted and/or signed messages with their base. Whether or not a domain based service is inherently better or worse than desktop based solutions is an open question. Some experts believe that only end-to-end solutions can be truly made secure, while others believe that the benefits offered by such things as content checking at domain boundaries offers considerable increase in practical security for many real systems. The additional service of allowing signature checking at several points on a communications path is also an extra benefit in many situations. This debate is outside the scope of this document. What is offered here is a set of tools that integrators can tailor in different ways to meet different needs in different circumstances. Message transfer agents (MTAs), guards, firewalls and protocol translation gateways all provide domain security services. As with desktop based solutions, these components must be resilient against a wide variety of attacks intended to subvert the security services. Therefore, careful consideration should be given to security of these components, to make sure that their siting and configuration minimises the possibility of attack. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. 2. Overview of Domain Security Services This section gives an informal overview of the security services that are provided by S/MIME between different security domains. These services are provided by a combination of mechanisms in the sender's and recipient's domains. Later sections describe definitively how these services map onto elements of the S/MIME protocol. The following security mechanisms are specified in this document: 1. Domain signature 2. Review signature 3. Additional attributes signature 4. Domain encryption and decryption The term 'security domain' as used in this document is defined as a collection of hardware and personnel operating under a single security authority and performing a common business function. Members of a security domain will of necessity share a high degree of mutual trust, due to their shared aims and objectives. A security domain is typically protected from direct outside attack by physical measures and from indirect (electronic) attack by a combination of firewalls and guards at network boundaries. The interface between two security domains is termed a 'security boundary'. One example of a security domain is an organisational network ('Intranet'). 2.1 Domain Signature A Domain signature is an S/MIME signature generated on behalf of a set of users in a domain. A Domain signature can be used to authenticate information sent between domains or between a certain domain and one of its individuals, for example, when two 'Intranets' are connected using the Internet, or when an Intranet is connected to a remote user over the Internet. It can be used when two domains employ incompatible signature schemes internally or when there are no certification links between their PKIs. In both cases messages from the originator's domain are signed over the original message and signature (if present) using an algorithm, key, and certificate which can be processed by the recipient(s). A domain signature is sometimes referred to as an "organisational signature". 2.2 Review Signature A third party may review messages before they are forwarded to the final recipient(s) who may be in the same or a different security domain. Organisational policy and good security practice often require that messages be reviewed before they are released to external recipients. Having reviewed a message, an S/MIME signature is added to it - a review signature. An agent could check the review signature at the domain boundary, to ensure that only reviewed messages are released. 2.3 Additional Attributes Signature A third party can add additional attributes to a signed message. An S/MIME signature is used for this purpose - an additional attributes signature. An example of an additional attribute is the 'Equivalent Label' attribute defined in ESS [3]. 2.4 Domain Encryption and Decryption Domain encryption is S/MIME encryption performed on behalf of a collection of users in a domain. Domain encryption can be used to protect information between domains, for example, when two 'Intranets' are connected using the Internet. It can also be used when end users do not have PKI/encryption capabilities at the desktop, or when two domains employ incompatible encryption schemes internally. In the latter case messages from the originator's domain are (re-)encrypted using an algorithm, key, and certificate which can be decrypted by the recipient(s) or an entity in their domain. This scheme also applies to protecting information between a single domain and one of its members when both are connected using an untrusted network, e.g the Internet. 3. Mapping of the Signature Services to the S/MIME Protocol This section describes the S/MIME protocol elements that are used to provide the security services described above. ESS [3] introduces the concept of triple-wrapped messages that are first signed, then encrypted, then signed again. This document also uses this concept of triple-wrapping. In addition, this document also uses the concept of 'signature encapsulation'. 'Signature encapsulation' denotes a signed or unsigned message that is wrapped in a signature, this signature covering both the content and the first (inner) signature, if present. Signature encapsulation MAY be performed on the inner and/or the outer signature of a triple-wrapped message. For example, the originator signs a message which is then encapsulated with an 'additional attributes' signature. This is then encrypted. A reviewer then signs this encrypted data, which is then encapsulated by a domain signature. A DOMSEC signature MAY encapsulate a message in one of the following ways: 1) An unsigned message has an empty signature layer added to it (i.e. the message is wrapped in a signedData that has a signerInfos which contains no elements). This is to enable backward compatibility with S/MIME software that does not have a DOMSEC capability. Since the signerInfos will contain no signers the eContentType, within the EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. However, the eContent field will contain the unsigned message instead of being left empty as suggested in section 5.2 in CMS [5]. This is so that when the DOMSEC signature is added, as defined in method 2) below, the signature will cover the unsigned message. 2) Signature Encapsulation is used to wrap the original signed message with a 'domain signature'. 3.1 Naming Conventions and Signature Types An entity receiving an S/MIME signed message would normally expect the signature to be that of the originator of the message. However, the message security services defined in this document require the recipient to be able to accept messages signed by other entities and/or the originator. When other entities sign the message the name in the certificate will not match the message sender's name. An S/MIME compliant implementation would normally flag a warning if there were a mismatch between the name in the certificate and the message sender's name. (This check prevents a number of types of masquerade attack.) In the case of domain security services, this warning condition SHOULD be suppressed under certain circumstances. These circumstances are defined by a naming convention that specifies the form that the signers name SHOULD adhere to. Adherence to this naming convention avoids the problems of uncontrolled naming and the possible masquerade attacks that this would produce. As an assistance to implementation, a signed attribute is defined to be included in the S/MIME signature - the 'signature type' attribute. On receiving a message containing this attribute, the naming convention checks are invoked. Implementations conforming to this standard MUST support the naming convention for signature generation and verification. Implementations conforming to this standard MUST recognise the signature type attribute for signature verification. Implementations conforming to this standard MUST support the signature type attribute for signature generation. 3.1.1 Naming Conventions The following naming conventions are specified for agents generating signatures specified in this document: * For a domain signature, an agent generating this signature MUST be named 'domain-signing-authority' * For a review signature, an agent generating this signature MUST be named 'review-authority'. * For an additional attributes signature, an agent generating this signature MUST be named 'attribute-authority'. This name shall appear as the 'common name (CN)' component of the subject field in the X.509 certificate. There MUST be only one CN component present. Additionally, if the certificate contains an RFC 822 address, this name shall appear in the end entity component of the address - on the left-hand side of the '@' symbol. In the case of a domain signature, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a domain signing authority, the domain component of its name MUST be the same as, or an ascendant of, the domain name of the message originator(s) that it is representing. The domain component is defined as follows: * In the case of an X.500 distinguished subject name of an X.509 certificate, the domain component is the country, organisation, organisational unit, state, and locality components of the distinguished name. * If the certificate contains an RFC 822 address, the domain component is defined to be the RFC 822 address component on the right- hand side of the '@' symbol. For example, a domain signing authority acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe, ou=marketing,o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, could have a certificate containing a distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and a RFC 822 address of 'domain-signing-authority@acme.com'. When the X.500 distinguished subject name has consecutive organisational units and/or localities it is important to understand the ordering of these values in order to determine if the domain component of the domain signature is an ascendant. In this case, when parsing the distinguished subject name from the root (i.e. country, locality or organisation) the parsed organisational unit or locality is deemed to be the ascendant of consecutive (unparsed) organisational units or localities. For example, a domain signing authority acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe, ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is John.Doe@marketing.defence.acme.com, could have a certificate containing a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme, c=us' and a RFC 822 address of 'domain-signing-authority@defence.acme.com'. Any message received where the domain component of the domain signing agents name does not match, or is not an ascendant of, the originator's domain name MUST be rejected. This naming rule prevents agents from one organisation masquerading as domain signing authorities on behalf of another. For the other types of signature defined in this document, no such named mapping rule is defined. Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages. On verifying the signature, a receiving agent MUST ensure that the naming convention has been adhered to. Any message that violates the convention should be flagged. 3.1.2 Signature Type Attribute An S/MIME signed attribute is used to indicate the type of signature. This should be used in conjunction with the naming conventions specified in the previous section. When an S/MIME signed message containing the signature type attribute is received it triggers the software to verify that the correct naming convention has been used. The ASN.1 [4] notation of this attribute is: - SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} If present, the SignatureType attribute MUST be a signed attribute, as defined in [5]. If the SignatureType attribute is absent the recipient SHOULD assume that the signature is that of the message originator. All of the signatures defined here are generated and processed as described in [5]. They are distinguished by the presence of the following values in the SignatureType signed attribute: id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 } -- domain signature. id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 3} -- additional attributes signature. id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- review signature. For completeness, an attribute type is also specified for an originator signature. However, this signature type is optional. It is defined as follows: id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1} -- originator's signature. All signature types, except the originator type, MUST encapsulate other signature types specified in this document MUST encapsulate other signatures. Note the domain signature could be encapsulating an empty signature as defined in section 3. A SignerInfo MUST NOT include multiple instances of SignatureType. A signed attribute representing a SignatureType MAY include multiple instances of different SignatureType values as an AttributeValue of attrValues [5], as long as the SignatureType 'additional attributes' is not present. If there is more than one SignerInfo in a signerInfos (i.e. when different algorithms are used) then the SignatureType attribute in all the SignerInfos MUST contain the same content. The following sections describe the conditions under which each of these types of signature may be generated, and how they are processed. 3.2 Domain Signature Generation and Verification A 'domain signature' is a proxy signature generated on a user's behalf in the user's domain. The signature MUST adhere to the naming conventions in 3.1.1, including the name mapping convention. A 'domain signature' on a message authenticates the fact that the message has originated in that domain. Before signing, a process generating a 'domain signature' MUST first satisfy itself of the authenticity of the message originator. This is achieved by one of two methods. Either the 'originator's signature' is checked, if S/MIME signatures are used inside a domain. Or if not, some mechanism external to S/MIME is used, such as the physical address of the originating client or an authenticated IP link. If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, a 'domain signature' MAY be added to a message. An entity generating a domain signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. When a 'domain signature' is applied the mlExpansionHistory and eSSSecurityLabel attributes MUST be copied from other signerInfos as stated in [3]. If the originator's authenticity is not successfully verified or all the signatures present are not valid, a 'domain signature' MUST NOT be generated. On reception, the 'domain signature' SHOULD be used to verify the authenticity of a message. A check MUST be made to ensure that both the naming convention and the name mapping convention have been used as specified in this standard. A recipient can assume that successful verification of the domain signature also authenticates the message originator. If there is an originator signature present, the name in that certificate SHOULD be used to identify the originator. This information can then be displayed to the recipient. If there is no originator signature present, the only assumption that can be made is the domain the message originated from. A domain signer can be assumed to have verified any signatures that it encapsulates. Therefore, it is not necessary to verify these signatures before treating the message as authentic. However, this standard does not preclude a recipient from attempting to verify any other signatures that are present. The 'domain signature' is indicated by the presence of the value id-aa-sigtype-domain-sig in a 'signature type' signed attribute. There MAY be one or more 'domain signature' signatures in an S/MIME encoding. 3.3 Additional Attributes Signature Generation and Verification The 'additional attributes' signature type indicates that the SignerInfo contains additional attributes that are associated with the message. All attributes in the applicable SignerInfo MUST be treated as additional attributes. Successful verification of an 'additional attributes' signature means only that the attributes are authentically bound to the message. A recipient MUST NOT assume that its successful verification also authenticates the message originator. An entity generating an 'additional attributes' signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. On reception, a check MUST be made to ensure that the naming convention has been used. A signer MAY include any of the attributes listed in [3] or in this document when generating an 'additional attributes' signature. The following attributes have a special meaning, when present in an 'additional attributes' signature: 1) Equivalent Label: label values in this attribute are to be treated as equivalent to the security label contained in an encapsulated SignerInfo, if present. 2) Security Label: the label value indicates the aggregate sensitivity of the inner message content plus any encapsulated signedData and envelopedData containers. The label on the original data is indicated by the value in the originator's signature, if present. An 'additional attributes' signature is indicated by the presence of the value id-aa-sigtype-add-attrib-sig in a 'signature type' signed attribute. Other Object Identifiers MUST NOT be included in the sequence of OIDs if this value is present. There MAY be multiple 'additional attributes' signatures in an S/MIME encoding. 3.4 Review Signature Generation and Verification The review signature indicates that the signer has reviewed the message. Successful verification of a review signature means only that the signer has approved the message for onward transmission to the recipient(s). When the recipient is in another domain, a device on a domain boundary such as a Mail Guard or firewall may be configured to check review signatures. A recipient MUST NOT assume that its successful verification also authenticates the message originator. An entity generating a signed review signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. On reception, a check MUST be made to ensure that the naming convention has been used. A review signature is indicated by the presence of the value id-aa-sigtype-review-sig in a 'signature type' signed attribute. There MAY be multiple review signatures in an S/MIME encoding. 3.5 Originator Signature The 'originator signature' is used to indicate that the signer is the originator of the message and its contents. It is included in this document for completeness only. An originator signature is indicated either by the absence of the signature type attribute, or by the presence of the value id-aa-sigtype-originator-sig in a 'signature type' signed attribute. 4. Encryption and Decryption Message encryption may be performed by a third party on behalf of a set of originators in a domain. This is referred to as domain encryption. Message decryption may be performed by a third party on behalf of a set of recipients in a domain. This is referred to as domain decryption. The third party that performs these processes is referred to in this section as a "Domain Confidentiality Authority" (DCA). Both of these processes are described in this section. Messages may be encrypted for decryption by the final recipient and/or by a DCA in the recipient's domain. The message may also be encrypted for decryption by a DCA in the originator's domain (e.g. for content analysis, audit, key word scanning, etc.). The choice of which of these is actually performed is a system specific issue that depends on system security policy. It is therefore outside the scope of this document. These processes of encryption and decryption processes are shown in the following table. -------------------------------------------------------------------- | | Recipient Decryption | Domain Decryption | |------------------------|----------------------|--------------------| | Originator Encryption | Case(a) | Case(b) | | Domain Encryption | Case(c) | Case(d) | -------------------------------------------------------------------- Case (a), encryption of messages by the originator for decryption by the final recipient(s), is described in CMS [5]. In cases (c) and (d), encryption is performed not by the originator but by the DCA in the originator's domain. In Cases (b) and (d), decryption is performed not by the recipient(s) but by the DCA in the recipient's domain. A client implementation that conforms to this standard MUST support case (b) for transmission, case (c) for reception and case (a) for transmission and reception. A DCA implementation that conforms to this standard MUST support cases (c) and (d), for transmission, and cases (b) and (d) for reception. The process of encryption and decryption is documented in CMS [5]. The only additional requirement introduced by domain encryption and decryption is for greater flexibility in the management of keys, as described in the following subsections. As with signatures, a naming convention and name mapping convention are used to locate the correct public key. The mechanisms described below are applicable both to key agreement and key transport systems, as documented in CMS [5]. The phrase 'encryption key' is used as a collective term to cover the key management keys used by both techniques. The mechanisms below are also applicable to individual roving users who wish to encrypt messages that are sent back to base. 4.1 Domain Confidentiality Naming Conventions A DCA MUST be named 'domain-confidentiality-authority'. This name MUST appear in the 'common name(CN)' component of the subject field in the X.509 certificate. Additionally, if the certificate contains an RFC 822 address, this name MUST appear in the end entity component of the address - on the left-hand side of the '@' symbol. Along with this naming convention, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a DCA, the domain component of its name MUST be the same as, or an ascendant of, the domain name of the set of entities that it represents. The domain component is defined as follows: * In the case of an X.500 distinguished name of an X.509 certificate, the domain component is the country, organisation, organisational unit, state, and locality components of the distinguished name. * If the certificate contains an RFC 822 address, the domain component is defined to be the RFC 822 address component on the right-hand side of the '@' symbol. For example, a DCA acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe, ou=marketing, o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, could have a certificate containing a distinguished name of 'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail address of 'domain-confidentiality-authority@acme.com'. The key associated with this certificate would be used for encrypting messages for John Doe. Any message received where the domain component of the domain encrypting agents name does not match, or is not an ascendant of, the domain name of the entities it represents MUST be rejected. This naming rule prevents messages being encrypted for the wrong domain decryption agent. Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations may choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to sending any messages. 4.2 Key Management for DCA Encryption At the sender's domain, DCA encryption is achieved using the recipient DCA's certificate or the end recipient's certificate. For this, the encrypting process must be able to correctly locate the certificate to the corresponding DCA in the recipient's domain or the one corresponding to the end recipient. Having located the correct certificate, the encryption process is then performed and additional information required for decryption is conveyed to the recipient in the recipientInfo field as specified in CMS [5]. A DCA encryption agent MUST be named according to the naming convention specified in section 4.1. This is so that the corresponding certificate can be used on eventual reply to a DCA encrypted message. DCA encryption may be performed for decryption by the end recipient and/or by a DCA. End recipient decryption is described in CMS [5]. DCA decryption is described in section 4.3. 4.3 Key Management for DCA Decryption DCA decryption uses a private-key from the recipient's domain and the necessary information conveyed in the recipientInfo field. The private-key is owned by the DCA for the recipient domain. This is achieved using the naming conventions specified in 4.1. It is vital that these conventions are adhered to, in order to maintain confidentiality. It should be noted that domain decryption can be performed on messages encrypted by the originator and/or by a DCA in the originator's domain. In the first case, the encryption process is described in CMS [5]; in the second case, the encryption process is described in 4.2. No specific method for locating this certificate is mandated in this document. An implementation may choose to access a local certificate store to locate the correct certificate. Alternatively, a directory may be used in one of the following ways: 1. The directory may store the DCA certificate in the recipient's directory entry. When the user certificate attribute is requested, this certificate is returned. 2. The encrypting agent maps the recipient`s name to the DCA name in the manner specified in 4.1. The user certificate attribute associated with this directory entry is then obtained. This document does not mandate either of these processes. Whichever one is used, the name mapping conventions must be adhered to, in order to maintain confidentiality. Having located the correct certificate, the encryption process is then performed. A recipientInfo for the DCA is then generated, as described in CMS [5]. 5. Security Considerations Implementations MUST protect all private keys. Compromise of the signer's private key permits masquerade. Similarly, compromise of the content-encryption key may result in disclosure of the encrypted content. Compromise of key material is regarded as an even more serious issue for domain security services than for an S/MIME client. This is because compromise of the private key may in turn compromise the security of a whole domain. Therefore, great care should be used when considering its protection. Domain encryption alone is not secure and should be used in conjuction with a domain signature to avoid a masquerade attack, where an attacker that has obtain a DCA cert can fake a message to that domain pretending to be another domain. 6. DOMSEC ASN.1 Module DOMSECSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- The types and values defined in this module are exported for -- use in the other ASN.1 modules. Other applications may use -- them for their own purposes. SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 } -- domain signature. id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 3} -- additional attributes signature. id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- review signature. id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1} -- originator's signature. END -- of DOMSECSyntax 7. References [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633, June 1999. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [4] International Telecommunications Union, Recommendation X.208, "Open systems interconnection: specification of Abstract Syntax Notation (ASN.1)", CCITT Blue Book, 1989. [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 8. Authors' Addresses Tim Dean DERA Malvern St. Andrews Road Malvern Worcs WR14 3PS Phone: +44 (0) 1684 894239 Fax: +44 (0) 1684 896660 Email: t.dean@eris.dera.gov.uk William Ottaway DERA Malvern St. Andrews Road Malvern Worcs WR14 3PS Phone: +44 (0) 1684 894079 Fax: +44 (0) 1684 896660 Email: w.ottaway@eris.dera.gov.uk 8. Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." This draft expires ??/??/?? working version ------=_NextPart_000_000B_01BFE5D0.1F28F780-- From owner-ietf-smime Tue Jul 4 13:49:39 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA26972 for ietf-smime-bks; Tue, 4 Jul 2000 13:49:39 -0700 (PDT) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26968 for ; Tue, 4 Jul 2000 13:49:38 -0700 (PDT) Received: from jimsch1t (ip187.du1.bel.nwlink.com [209.20.136.187]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id NAA15140 for ; Tue, 4 Jul 2000 13:50:53 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "Ietf-Smime" Subject: Comments on draft-ietf-smime-domsec-05.txt Date: Tue, 4 Jul 2000 13:51:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <4.2.0.58.20000621112157.00959aa0@mail.spyrus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Should the X.400 on hetrogenous messaging be expanded to X.400/P1 similar to SMTP/MIME 2. Section 1.0 bullet 4: Should be Heterogeneous Message Formats not transports. The problem is if you cannot carry the S/MIME content type not the wrapper on the message. (Microsoft Exchange actually uses X.400 headers with a custom content type for internal replication last time I checked and this did not break signatures on these messages as the MIME structure was carried intact.) 3. Section 1 last paragraph: change to more standard wording on MUST. 4. Section 2.1 formatting problem: "signature(if present)using" goes to "signature (if present) using" 5. Section 2.2 - remove MAY from the last sentence. This is a reason to do the signatures, but is not part of the protocol definition. -- change MAY to could. 6. Section 2.3 - ditto above comment for first sentence. You can do this, but it is not part of the protocol defintion. change MAY to can. 7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data" 8. Section 3.0 bullet 1: This concept bothers me. I think that there may be some programs out there that assume atleast one signature in a signed data object except for cases such as degenerate certs only messages. 9. Section 3.0 bullet 1: A better term for this might be a null (or empty) signature layer. This will difference the concept from the discussions about signing with the NULL signature algorithm. 10. Section 3.0 bullet 2: This not clear about the presence (or absense) of a MIME layer. If MIME layer exists, then I fail to see the need for bullet 1 at all. 11. Section 3.0 Para 1: Simple example of why counter-signature and parallel signatures do or don't work for this might be called for. 12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad - review-authority" is legal (difference between 'in' and 'as'. Additionally you might want to do capitalization here as utf8 strings do not do case insensitive name compararisions (i.e. Review-Authority). Also is cn="Jim Schaad" cn="review-authority" legal? [By definition I think that this would only need to be done if the review was on the innermost signature layer. On outer layers I don't believe the intent was that name checking of the certificate and sender should occur otherwise signing MLAs will create lots of havoc.] 13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be explicity forbidden? 14. Section 3.1.1 Last Paragraphy - Please soften last sentence. The correct action should be to flag sender/certificate mismatch not to reject as invalid. 15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a description of generating and processing siganture types. I believe that you meant "All signatures are processed..." 16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using the -- comment syntax of ASN. i.e. id-aa-sigtype-domain-signature :: OBJECT ID {....} -- Domain Signature 17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about originator signature not ecapuslating other signatures -- you are eleminating triple wrapped signature from existance (i.e. S2(E(S1(M))) where S1 and S2 are by the originator. 18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same level have different content in the SigantureType attribute or not? 19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you must remove the mlaExpansion or the first MLA outside will strip the domain signature from the message. 20. Section 3.2 Paragarph 11 - Why is this only a MAY. It would appear that the correct statement is MUST as otherwise the whole process is wasted. 21. Section 3.2 Paragaph ? - Where and how did you get the FROM address in the message. Unless you make a statement about including the SMTP headers at the time of wrapping all you get is the MIME headers which do not include this information. (i.e. this is never going to happen unless you call for it to happen.) 22. Section 3.2 Last Paragraph - Change to make a statement about a single layer as well (or instead of). 23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS? 24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))). S1 has an equivalent label, S2 and S3 both have labels, and the labels are different. Is the equivalent label the same as both labels or only one? 25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST 26. Section 3.3 Paragarph Last - ditto froms ection 3.3 27. Section 3.5 - By default you can have multiple originator signatures (potentially with different algorithms) in a message. So the restriction in this section makes no sense. 28. Section 4 - Where on this table would you put the case of Originator Encrypts to Recipient Domain which encrypts to Receipient? It would appear to be an instance of (a), (b) and (c). 29. Section 4 Paragraphy Last-2 - How can I possibly enforce this? For Key Transport the sender is anonymous, for Key Agreement the senders certificate is often not examined. Additionally the domain component could change so that does match -- or it might be my domain component that did the re-enecryption and would therefore match my domain name and not the senders domain name. 30. General - Please include ASN.1 module at the end with a list of all defined OIDs and structures. Get module oid from Russ. (This request is just pure lazyness on my part but makes some things easier.) 31. General - Do we need to specify the big brother syndrome at this time (encrypt for end-entity and for DCA)? jim schaad From owner-ietf-smime Wed Jul 5 08:12:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13706 for ietf-smime-bks; Wed, 5 Jul 2000 08:12:35 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13702 for ; Wed, 5 Jul 2000 08:12:34 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA05037 for ; Wed, 5 Jul 2000 08:13:21 -0700 (PDT) Message-Id: <4.2.0.58.20000705085731.00afd500@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jul 2000 09:00:46 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: draft-ietf-smime-idea-05.txt In-Reply-To: <200006271044.GAA06317@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The new draft still contains the following ASN.1 for the IDEA Parameters: IDEA-CBCPar ::= SEQUENCE { IV OCTET STRING OPTIONAL -- exactly 8 octets } First, the ASN.1 has an error because the '}' is within a comment. Second, I see no reason for the SEQUENCE. Has code already been written and deployed that uses this syntax? Russ At 06:44 AM 06/27/2000 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the S/MIME Mail Security Working Group of the >IETF. > > Title : Use of the IDEA Encryption Algorithm in CMS > Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi > Filename : draft-ietf-smime-idea-05.txt > Pages : 6 > Date : 26-Jun-00 > >This memo specifies how to incorporate IDEA (International Data >Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as >an additional strong algorithm for symmetric encryption. For >organizations who make use of IDEA for data security purposes >it is of high interest that IDEA is also available in S/MIME. >The intention of this memo is to provide the OIDs and algorithms >required that IDEA can be included in S/MIME for symmetric content >and key encryption. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-05.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-smime-idea-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-smime-idea-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000626113158.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-smime-idea-05.txt > > From owner-ietf-smime Thu Jul 6 12:10:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28059 for ietf-smime-bks; Thu, 6 Jul 2000 12:10:44 -0700 (PDT) Received: from mail.treasureweb.com.hk ([152.101.116.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28053 for ; Thu, 6 Jul 2000 12:10:42 -0700 (PDT) Received: from host [38.26.242.162] by mail.treasureweb.com.hk with ESMTP (SMTPD32-5.05) id AD2765C028E; Mon, 12 Jun 2000 00:11:35 +0800 From: "Carter Mellis" Subject: Your business depends on it #7DB7 To: cash29d X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 11 Jun 2000 11:25:38 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200006120011109.SM00247@host> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA28055 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Email marketing is starting to boom and you're probably wondering how you can capitalize on this phenomenal advertising method. Well..here is your chance! As e-commerce grows, you need to stay on top of your competition and keep up with the technology. GENIUS MARKETING STRATEGIES CAN HELP! We can target a market that will advertise your business effectively. NATIONWIDE OR LOCAL TARGETING IS AVAILABLE! You've probably seen millions of email addresses on CD's for $50 or lots of companies offering deals that seem too good to be true... Well, they are! We are professional email marketers who take pride in our excellent customer service. RATED #1 EMAIL MARKETERS IN ENTREPRENEUR MAGAZINE Get a head start on your competition today with FREE ADVERTISING CONSULTING from Genius Marketing Strategies. Reply to mailto:genmark@bigfoot.com include your: Name: e-mail address: Phone# Web site address: Best time to reach: Preferred to be contacted by EMAIL or PHONE (ALL INFORMATION MUST BE INCLUDED) We except: VISA, MASTER CARD, AND AMERICAN EXPRESS OR CHECK BY FAX OR PHONE. *********************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply to: mailto:merch345@yahoo.com?subject=remove ************************************************************ From owner-ietf-smime Fri Jul 7 02:58:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA03263 for ietf-smime-bks; Fri, 7 Jul 2000 02:58:07 -0700 (PDT) Received: from citicorp.com ([192.193.195.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03259 for ; Fri, 7 Jul 2000 02:58:05 -0700 (PDT) From: bartley.omalley@citicorp.com Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.195.186]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA04500 for ; Fri, 7 Jul 2000 05:54:47 -0400 (EDT) Received: from x400prod2.cgin.us-md.citicorp.com (root@omroute3lan1.email.citicorp.com [163.39.249.91]) by myrtle1.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA02593 for ; Fri, 7 Jul 2000 05:57:05 -0400 (EDT) Received: from mercury.lew.gb.citicorp.com (mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA26972 Fri, 7 Jul 2000 05:57:04 -0400 (EDT) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02206 for ietf-smime@imc.org; Fri, 7 Jul 2000 10:57:02 +0100 (BST) X-OpenMail-Hops: 1 Date: Fri, 7 Jul 2000 10:56:57 +0100 Message-Id: Subject: FW: Canonicalisation of embedded MIME objects MIME-Version: 1.0 TO: ietf-smime@imc.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I posted this earlier but got only one response and no help. Can anyone help or point me in the right direction where I may find clarification. I am aware that the standards say "be modest in what you send and generous in what you accept" but It seems that a significant number of people/implementers are not following the standard as defined. Bartley. -----Original Message----- From: O'Malley, Bartley Sent: Friday, June 23, 2000 1:03 PM To: 'ietf-smime' Subject: Canonicalisation of embedded MIME objects I have noticed that a number of files as produced by different mail programs do not seem to be performing canonicalisation of inner objects correctly. The inner objects use LF for line termination not CRLF pairs. It is my understanding that breaks MIME rules for canonicalising embedded objects. To illustrate the problem I enclose a signed-then-encrypted message I have received:(I have removed the routing information) The outer message appears as follows(All lines are terminated with pairs.). ----------------------------------------------------------- Content-Type: application/pkcs7-mime; smime-type=encrypted-data; name="xxx.p7m" Content-Disposition: attachment; filename=xxx.p7m Content-Transfer-Encoding: base64 Message-ID: 19991015:080159:REF12345 MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1UEBhMCVVMx ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW50IDICBDUa : : VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC4RdXrwyH2l 1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WYEo+aKglqhJ -------------------------------------------------------------------------------- ---- The embedded message looks as follows(All lines are terminated with ). ---------------------------------------------------------------------------- Content-Type: application/pkcs7-mime; smime-type=signed-data; name="xxx.p7m" Content-Disposition: attachment; filename=xxx.p7m Content-Transfer-Encoding: base64 Message-ID: 19990225:131734:20499 MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKoZIhvcNAQcB : : mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSlvuG6deAhgZ XJ0KskSW4qT5 ----------------------------------------------------------------------------- The inner application file looks as follows: With Content lines terminated with and the data segment with no line ends. ---------------------------------------------------------------------------- Content-Type: application/EDIFACT; name="xxx.edi" Content-Transfer-Encoding: binary UNA:+.? 'UNB+UNOA:1+ ----------------------------------------------------------------------------- It is my interpretation that the use of to terminate the Content headers in the latter two messages above is not valid. Can someone provide me with a definitive answer. Thanks, Bartley. From owner-ietf-smime Fri Jul 7 04:22:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA08558 for ietf-smime-bks; Fri, 7 Jul 2000 04:22:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08552 for ; Fri, 7 Jul 2000 04:22:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20992; Fri, 7 Jul 2000 07:23:53 -0400 (EDT) Message-Id: <200007071123.HAA20992@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-seclabel-01.txt Date: Fri, 07 Jul 2000 07:23:52 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Implementing Company Classification Policy with the S/MIME Security Label Author(s) : W. Nicolls Filename : draft-ietf-smime-seclabel-01.txt Pages : Date : 06-Jul-00 This document discusses how company security policy for data classification can be mapped to the S/MIME classification label. Actual policies from 3 companies are used to provide worked examples. Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both. The syntax and processing rules for security labels are described in [ESS]. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [MUSTSHOULD]. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-seclabel-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-seclabel-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-seclabel-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706152320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-seclabel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-seclabel-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706152320.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Fri Jul 7 09:52:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23831 for ietf-smime-bks; Fri, 7 Jul 2000 09:52:30 -0700 (PDT) Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23827 for ; Fri, 7 Jul 2000 09:52:29 -0700 (PDT) Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id MAA20865; Fri, 7 Jul 2000 12:53:51 -0400 (EDT) Message-ID: <39660AB1.82E2FD87@ieca.com> Date: Fri, 07 Jul 2000 12:52:01 -0400 From: Sean Turner Organization: IECA, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jimsch@nwlink.com, Sharon Boeyen CC: ietf-smime@imc.org Subject: Re: SMIME cert dist draft and X.509 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim and Sharon, The biggest concern I have is the duplication of certificates in directory and finding certification path. The CertificateSet, which is required to be present in SMimeCertificatePublish object, is a set of certificates that MUST be present. It contains a "bucket-o-certs" for the user certificates and CA certificates. If we could replace it with a pointer to the user certificate and CA certificates it would solve this duplication problem. PKIPath couldn't be used because it too is not a pointer. Could we use something like (hack my ASN.1 as you please) the following instead of CertificateSet: CertificatesForSMIME ::= SEQUENCE { sMIMEUserCertificate CertificateIdentifier, sMIMECACertificates SEQUENCE OF CertificateIdentifier } CertificateIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier } This would solve the problem of duplication and it would provide the certificate path. This won't solve the problem of backwards compatibility though. So maybe we could use the following instead of CertificateSet too: CertificateForSMIME ::= CHOICE { actualCertificates CertificateSet, -- For backward compatibility with Netscape and Microsoft code pointerToCertficates CertificatesForSMIME } Thoughts? Other issues: - Using SMIMECapabilities instead of supportAlgorithms To be honest I don't have a preference. supportAlgorithms is in X.500 but SMIMECapabilities is in an RFC. Both are implemented. - Using attribute certificates to bind algorithm instead of SMIMECapabilities I think while it should be a goal to use attribute certificates to bind the algorithms to the certificates I don't think we're there yet (some maybe but not most). We probably don't want to wait for everbody to implement attribute certificates before implementing this mechanism. Cheers, spt Jim Schaad wrote: > Sharon, > > There were a number of limitations that are in X509 that I was trying to > overcome with this draft: > > The supportedAlgorithms field was not used for two reasons, first I did not > know about it when this started and secondly attribute certificates were not > defined at the time the problem was addressed, thus they were not a part of > every S/MIME application already. The use of the SignedData structure means > that we are re-using already existing code in every S/MIME application. > (The exact same mechinism is used for transfering the information when > sending a signed message between two entities.) > > Given that we are living in an LDAP world rather than an X509 world, using > isser DNs of certificates to attempt to find an issuer certificate is an > extremely difficult problem. Add to this the questions of > companies/individuals not publishing intermeadiate CA certificates or making > them private (although the CRL might be available from a non-directory > location) and I don't know that in the internet world that the certificate > retrevial portion of path construction is viable. > > While I agree that this problem might have been better considered in the > PKIX working group as the problem is universion, however the problem and the > solution was first found by S/MIME developers and the chair of the group > agreed that it was a reasonable problem to be put before the group. > Additionally, the solution used some items that were defined by the working > group in the S/MIME documents rather than in PKIX documents. Lastly, the > PKIX group is still very X509 directory centric in many of it's solutions > while the S/MIME working group is extremely LDAP centric. Thus what seems > to be a problem for the S/MIME working group might not be a problem for the > PKIX working group (such as finding CA certificates without an X509 > directory). > > Additionally please note that we have not solved the general path > construction problem, we have only made it easier (since the holder of the > certificate is in a better situation to build their own path) for the sender > to avoid the problem. In the event that the PKIX group came up with a > viable method of doing path discovery then this draft can be revised so that > the full path information was not required in the attribute even though > there are situations (i.e. offline or non-directory location of the > attribute) where it might be useful. > > jim schaad > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Sharon Boeyen > Sent: Friday, June 02, 2000 11:42 AM > To: 'ietf-smime@imc.org' > Subject: SMIME cert dist draft and X.509 > > I am not a regular participant on this mailing list, and therefore lack the > history behind this draft. However, as editor of X.509, I'm wondering why > this draft invents new data structures for requirements that, after a very > quick review, I think that X.509 already has standardized structures to > support. From a 509 perspective, I certainly want to understand any > shortcomings that specification has with respect to meeting the needs of the > applications that use public-key certificates. > > Regarding SMimeCapabilities themeselves; was the supportedAlgorithms > attribute from 509 considered? If so, were there specific shortcomings that > it had? Note that it is defined in X.509 as an attribute. Attributes can be > stored in > directories as part of entries (with or without being digitally signed > and/or encrypted), they can be transferred in application protocols, they > can be included in public-key and attribute certificates. > > Regarding the requirement to tie a set of supported algorithms to a specific > certificate; the construct defined in the Internet draft is semantically an > attribute certificate. Was an X.509 attribute certificate considered and > rejected? If so, what were its deficiencies? Note that there are a number of > ways to identify the holder of an X.509 attribute certificate. One of those > is the hash of a public-key certificate. An attribute certificate that > contained the hash of a public-key certificate and the supportedAlgorithms > attribute seems to provide the functionality you're looking for. If you want > a construct that includes several iterations (i.e. the set of algorithms > for each public-key certificate), then the X.509 construct > attributeCertificateAttribute seems to provide this because it is a > multivalued attribute that contains values of the attributeCertificate > construct. Again, these can be stored in directories, stored in files, > transferred in application protocols etc. > > Regarding PKI path construction; this is an area where a number of different > groups seem to be active. I'm curious why there would be an smime specific > mechanism for this anyway, when if there really is a problem, its probably > not unique > to smime. PKIX seems like a better place to solve this problem. I'm not sure > I really understand your proposed solution. Are you focused only on > hierarchies or also addressing networked trust models? Why store the path > with the subject's domain when its the relying party's domain where the > information is needed. Why associate it with a user certificate at all, > since the same path (less the user cert) can be reused for any user certs > signed by the same CA? X.509 has a standard attribute called pkiPath that I > think may satisfy the requirement. This attribute contains a sequence of > CA-certificates and its intent is that it stores paths that are frequently > used by the relying parties within the community of a given CA. As such, it > can be used to reduce the number of network connections and directory (or > other protocol) requests to external domains. It is intended to be an > optional facility that may be useful in some environments, but not necessary > in others. > > With respect to all of these, my view is that, if directories are being used > as repositories for the information, then ALL public-key certificates issued > to a user be stored in the userCertificate attribute of their directory > entry. This eliminates the need for specialized application-specific tools > on the relying party side to find application specific data. If there are > enhanced mechansims that provide potential efficiencies in an application > specific environment these > should be optional enhancements and not eliminate the fundamental > interoperability requirement to store information in a common place. I hold > the same view with respect to the pkiPath attribute. If stored in a > directory it should not eliminate the need to store information as defined > in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate > attributes. > > I apologize in advance if, due to my lack of knowledge of the history of > this spec, I'm asking questions that have been previously dealt with and > closed, but felt I should at least ask, in the capacity of X.509 editor. > > FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or > pdf format from the following: > > ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ > > This text has been approved by ITU and is the 2000 edition of X.509, > although many of things I mention were in the 1997 3rd edition text as well. > > Sharon > > Sharon Boeyen > Entrust Technologies > sharon.boeyen@entrust.com From owner-ietf-smime Mon Jul 10 02:41:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA17993 for ietf-smime-bks; Mon, 10 Jul 2000 02:41:45 -0700 (PDT) Received: from citicorp.com (mango2.citicorp.com [192.193.195.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17989 for ; Mon, 10 Jul 2000 02:41:44 -0700 (PDT) From: bartley.omalley@citicorp.com Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.195.186]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA00913; Mon, 10 Jul 2000 05:39:53 -0400 (EDT) Received: from x400prod2.cgin.us-md.citicorp.com (root@omroute3lan1.email.citicorp.com [163.39.249.91]) by myrtle1.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27625; Mon, 10 Jul 2000 05:42:53 -0400 (EDT) Received: from mercury.lew.gb.citicorp.com (mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA13850; Mon, 10 Jul 2000 05:42:52 -0400 (EDT) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02917; Mon, 10 Jul 2000 10:44:47 +0100 (BST) X-OpenMail-Hops: 1 Date: Mon, 10 Jul 2000 10:44:37 +0100 Message-Id: Subject: RE: RE: Canonicalisation of embedded MIME objects MIME-Version: 1.0 TO: zahid.ahmed@commerceone.com CC: ietf-smime@imc.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ahmed, thanks for your reply. The canonicalisation I refer to is defined in RFC45 section 6.6 page 19 and more specifically again in RFC2049 section 4 subsection 2 second paragraph page 10. It states: "For example in the case of text/plain data, the text must be converted to a supported character set and lines must be delimited with CRLF delimiters in accordance with RFC 822..." It is my interpretation that ALL embedded objects must have valid line ends on their MIME headers. ALL body parts, except binary, must also have valid line ends. Just as the outer MIME message has. Your comments will be very much appreciated. Regards, Bartley. -----Original Message----- From: zahid.ahmed [SMTP:zahid.ahmed@commerceone.com] Sent: Saturday, July 08, 2000 1:45 AM To: bartley.omalley Cc: zahid.ahmed Subject: RE: Canonicalisation of embedded MIME objects can you define what you mean by Canonicalisation of multipart mime? What specific requirements and assumption you have? thanks, Zahid Ahmed > -----Original Message----- > From: bartley.omalley@citicorp.com > [mailto:bartley.omalley@citicorp.com] > Sent: Friday, July 07, 2000 2:57 AM > To: ietf-smime@imc.org > Subject: FW: Canonicalisation of embedded MIME objects > > > I posted this earlier but got only one response and no help. > > Can anyone help or point me in the right direction where I may find > clarification. > > I am aware that the standards say "be modest in what you send > and generous in > what you accept" but It seems that a significant number of > people/implementers > are not following the standard as defined. > > Bartley. > > -----Original Message----- > From: O'Malley, Bartley > Sent: Friday, June 23, 2000 1:03 PM > To: 'ietf-smime' > Subject: Canonicalisation of embedded MIME objects > > I have noticed that a number of files as produced by > different mail programs do > not seem to be performing canonicalisation of inner objects correctly. > > The inner objects use LF for line termination not CRLF pairs. > It is my > understanding that breaks MIME rules for canonicalising > embedded objects. > > To illustrate the problem I enclose a signed-then-encrypted > message I have > received:(I have removed the routing information) > > The outer message appears as follows(All lines are terminated > with > pairs.). > ----------------------------------------------------------- > Content-Type: application/pkcs7-mime; > smime-type=encrypted-data; > name="xxx.p7m" > > Content-Disposition: attachment; filename=xxx.p7m > > Content-Transfer-Encoding: base64 > > Message-ID: 19991015:080159:REF12345 > > > > MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1 > UEBhMCVVMx > ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW > 50IDICBDUa > : > : > VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC > 4RdXrwyH2l > 1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WY > Eo+aKglqhJ > -------------------------------------------------------------- > ------------------ > ---- > > > The embedded message looks as follows(All lines are > terminated with ). > > -------------------------------------------------------------- > -------------- > Content-Type: application/pkcs7-mime; smime-type=signed-data; > name="xxx.p7m" > Content-Disposition: attachment; filename=xxx.p7m > Content-Transfer-Encoding: base64 > Message-ID: 19990225:131734:20499 > > MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKo > ZIhvcNAQcB > : > : > mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSl > vuG6deAhgZ > XJ0KskSW4qT5 > -------------------------------------------------------------- > --------------- > > > The inner application file looks as follows: With Content > lines terminated with > and the data segment with no line ends. > > -------------------------------------------------------------- > -------------- > Content-Type: application/EDIFACT; > name="xxx.edi" > Content-Transfer-Encoding: binary > > UNA:+.? 'UNB+UNOA:1+ > > > > -------------------------------------------------------------- > --------------- > > > It is my interpretation that the use of to terminate the > Content headers > in the latter two messages above is not valid. > > Can someone provide me with a definitive answer. > > Thanks, > Bartley. > > > > > From owner-ietf-smime Wed Jul 12 17:13:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06895 for ietf-smime-bks; Wed, 12 Jul 2000 17:13:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06891 for ; Wed, 12 Jul 2000 17:13:11 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA13974; Wed, 12 Jul 2000 17:15:08 -0700 (PDT) Message-Id: <200007130015.RAA13974@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2876 on KEA and SKIPJACK Algorithms in CMS Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 12 Jul 2000 17:15:08 -0700 From: RFC Editor Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2876 Title: Use of the KEA and SKIPJACK Algorithms in CMS Author(s): J. Pawling Status: Informational Date: July 2000 Mailbox: john.pawling@wang.com Pages: 13 Characters: 29265 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-cmskea-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2876.txt This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. This document is the product of the S/MIME Mail Security Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000712171255.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2876 --OtherAccess Content-Type: Message/External-body; name="rfc2876.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000712171255.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Jul 13 03:27:23 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA15793 for ietf-smime-bks; Thu, 13 Jul 2000 03:27:23 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15789 for ; Thu, 13 Jul 2000 03:27:21 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11455; Thu, 13 Jul 2000 06:29:21 -0400 (EDT) Message-Id: <200007131029.GAA11455@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-domsec-06.txt Date: Thu, 13 Jul 2000 06:29:21 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Domain Security Services using S/MIME Author(s) : T. Dean, W. Ottaway Filename : draft-ietf-smime-domsec-06.txt Pages : 8 Date : 12-Jul-00 This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely, for example when two domains use incompatible messaging technologies such as X.400 series and SMTP/MIME, or when a single domain wishes to communicate securely with one of its members residing on an untrusted domain. The scenarios covered by this document are domain to domain, individual to domain and domain to individual communications. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-domsec-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-domsec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712140759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-domsec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-domsec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140759.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Jul 13 06:05:11 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23527 for ietf-smime-bks; Thu, 13 Jul 2000 06:05:11 -0700 (PDT) Received: from sol.fem.com.br ([200.202.236.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23520 for ; Thu, 13 Jul 2000 06:05:08 -0700 (PDT) Received: from djdswk ([209.206.0.87]) by sol.fem.com.br (Netscape Messaging Server 3.6) with ESMTP id AAA2DB1; Thu, 13 Jul 2000 10:00:37 -0300 From: "Nora grenberg" Subject: You First... #6038 To: open39d@sol.fem.com.br X-Mailer: QUALCOMM Windows Eudora Light Version 4.0 (32) Mime-Version: 1.0 Date: Thu, 13 Jul 2000 05:47:19 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7736AA9016C4.AAA2DB1@sol.fem.com.br> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA23524 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e -commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:edgld@populus.net?subject=INFO-PLEASE to receive our FREE e-mail information package without obligations. ********************************************************* Remove at mailto:moxtm@eudoramail.com?subject=remove ********************************************************* From owner-ietf-smime Fri Jul 14 03:54:46 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16177 for ietf-smime-bks; Fri, 14 Jul 2000 03:54:46 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16173 for ; Fri, 14 Jul 2000 03:54:44 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10841; Fri, 14 Jul 2000 06:56:49 -0400 (EDT) Message-Id: <200007141056.GAA10841@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-esformats-01.txt Date: Fri, 14 Jul 2000 06:56:49 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Electronic Signature Formats for long term electronic signature Author(s) : D. Pinkas, J. Ross, N. Pope Filename : draft-ietf-smime-esformats-01.txt Pages : 75 Date : 13-Jul-00 The informational RFC defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e. repudiates, see [ISONR]) the validity of the signature. The format can be considered as an extension to RFC 2630 [CMS] and RFC 2634 [ESS], where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC is technically equivalent to ETSI ES 201 733 V.1.1.3 Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-esformats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-esformats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-esformats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-esformats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145903.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Fri Jul 14 14:03:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA14955 for ietf-smime-bks; Fri, 14 Jul 2000 14:03:22 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14951; Fri, 14 Jul 2000 14:03:21 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <3GNFB431>; Fri, 14 Jul 2000 17:04:54 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D013E@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.7 S/MIME Freeware Library Now Available Date: Fri, 14 Jul 2000 17:04:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Wang Government Services, Inc. (WGSI), A Getronics Company, has delivered Version 1.7 of the S/MIME Freeware Library (SFL) source code and Application Programming Interface (API). The SFL source code files are freely available to everyone from the Fortezza Developer's S/MIME Page . The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H, 3DES) provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by the RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The SFL uses the v1.3 Enhanced SNACC ASN.1 Library to encode/decode objects. The v1.7 SFL release includes: SFL High- level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); v1.3 Enhanced SNACC ASN.1 Compiler and Library; test utilities; test drivers and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Solaris 2.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X S/MIME v2 products. Signed messages have been exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 2630, 2631 and 2634. This testing included the RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We used the SFL to successfully process all of the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We have also performed limited S/MIME v3 testing with Baltimore and Entrust. The following enhancements are included in the v1.7 SFL release (compared with the v1.6 release): 1) Tested using new, consolidated SNACC library and other common libraries shared with the v1.3 Access Control Library (ACL) and v1.71 Certificate Management Library (CML). 2) Re-configured directory structure for SFL source code files so that it is consistent with the ACL and CML. 3) Corrected bugs in SPEX/ CTIL. Successfully used SPEX/ CTIL to provide RSA key management and DES using the Spyrus SPEX/ Library v1.52b Release 7b, Spyrus Lynks Card and X.509 v3 Certificates created by the Spyrus S2CA. We also tested SHA1-with-RSA signature creation/verification using the Lynks Card. We also tested the Fortezza algorithm suite using a Fortezza Card. 4) Corrected several bugs reported by customers. 5) Performed regression testing to ensure that aforementioned enhancements did not break existing SFL functionality. We are still in the process of enhancing and testing the SFL. Future releases will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line utility; enhancing CertificateBuilder to support creation of Attribute Certificates; modify PKCS #12 code in test utilities to provide interoperable key storage; add MIME support for test drivers; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; support for other crypto APIs (possible); and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows and Solaris 2.7, we plan to port the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 (possibly), SCO 5.0 (possibly) and Macintosh (possibly). The following SFL files are available from the Fortezza Developer's S/MIME Page: 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) snacc13rn.tar.gz: Zip file containing v1.3 Enhanced SNACC ASN.1 Compiler and Library source code compilable for Unix and MS Windows NT/95/98/2000 that has been enhanced by WGSI to implement the Distinguished Encoding Rules. Project files and makefiles are included. This file includes a sample test project demonstrating the use of the SNACC classes. 3) smimeR1.7.tar.gz: Zip file containing all SFL source code including: SFL Hi-Level source code; Enhanced SNACC-generated ASN.1 source code; project files. This file also contains test driver source code, sample CMS/ESS test data and test X.509 Certificates. This file also includes test utilities to create X.509 Certificates that each include a D-H, DSA or RSA public key. SNACC release and debug libraries are compiled for MS Windows NT/95/98/2000. MS Windows NT/95/98/2000 project files and Unix makefiles are included for the SNACC code and Crypto++. 4) smCTIR1.7.tar.gz: Source code for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11. The Win95/98/NT/2000 projects are also included. (NOTE: The Free (a.k.a. Crypto++) CTIL includes WGSI-developed source code to use the RSA public key algorithm implemented within the external Crypto++ library. As with all of the external crypto token libraries, the Crypto++ library is not distributed as part of the SFL source code. To use the Crypto++ library with the SFL, the application developer must independently obtain the Crypto++ library from the Crypto++ Web Page and then compile it with the WGSI-developed Crypto++ CTIL source code. The RSA public key algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication System and Method". Within the U.S., users of the RSA public key algorithm provided by the external Crypto++ library must obtain a license from RSA granting them permission to use the RSA algorithm.) 5) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. WGSI is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License" available from the Fortezza Developer's S/MIME Page. On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. For example, the SFL uses the freeware Crypto++ library to obtain 3DES, D-H and DSA. To use the SFL with Crypto++ the vendor must download the Crypto++ freeware library from the Crypto++ Web Page and then compile it with the WGSI-developed Crypto++ CTIL source code. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-ietf-smime Sat Jul 15 11:48:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02245 for ietf-smime-bks; Sat, 15 Jul 2000 11:48:22 -0700 (PDT) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02241 for ; Sat, 15 Jul 2000 11:48:21 -0700 (PDT) Received: from 207-172-49-64.s64.tnt7.lnhva.md.dialup.rcn.com ([207.172.49.64] helo=rhousley_laptop) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13DX1F-0007Yf-00; Sat, 15 Jul 2000 14:50:33 -0400 Message-Id: <4.2.0.58.20000715135822.00a7b240@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 15 Jul 2000 14:02:27 -0400 To: agenda@ietf.org From: Russ Housley Subject: DRAFT S/MIME WG Aganda Cc: ietf-smime@imc.org In-Reply-To: <200007122232.SAA17284@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here is the DRAFT agenda for the S/MIME WG on 31 July 2000. Russ = = = = = = = = = * Introductions Russ Housley * Working Group Status Russ Housley * CMS/ESS Examples Paul Hoffman * Interoperability Matrix Jim Schaad * CERTDIST Draft Discussion Jim Schaad * Security Policies and Labels Weston Nicolls * Symmetric Key Distribution Sean Turner * DOMSEC Draft Discussion Bill Ottaway * Electronic Signature Formats Denis Pinkas * Signature Policy Format Denis Pinkas * Wrap up Russ Housley From owner-ietf-smime Wed Jul 19 03:33:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA23945 for ietf-smime-bks; Wed, 19 Jul 2000 03:33:14 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23940 for ; Wed, 19 Jul 2000 03:33:13 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21606; Wed, 19 Jul 2000 06:35:43 -0400 (EDT) Message-Id: <200007191035.GAA21606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-espolicies-00.txt Date: Wed, 19 Jul 2000 06:35:43 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Electronic Signature Policies Author(s) : J. Ross, D. Pinkas, N. Pope Filename : draft-ietf-smime-espolicies-00.txt Pages : 42 Date : 18-Jul-00 This RFC defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1. The contents of this RFC is based on the signature policy defined in ETSI ES 201 733 V.1.1.3(2000-05) Copyright (C). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-espolicies-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-espolicies-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-espolicies-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000718140715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-espolicies-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-espolicies-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718140715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Jul 24 12:59:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for ; Mon, 24 Jul 2000 12:59:11 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for ietf-123-outbound.05@ietf.org; Mon, 24 Jul 2000 15:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for ; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Message-Id: <200007241038.GAA09375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt Date: Mon, 24 Jul 2000 06:38:44 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-01.txt Pages : 55 Date : 21-Jul-00 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Jul 24 13:10:52 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20223 for ietf-smime-bks; Mon, 24 Jul 2000 13:10:52 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20219 for ; Mon, 24 Jul 2000 13:10:50 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA05169; Mon, 24 Jul 2000 13:13:48 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA05145; Mon, 24 Jul 2000 13:13:48 -0700 (PDT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com with ESMTP id NAA12565; Mon, 24 Jul 2000 13:14:22 -0700 (PDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20180 for ietf-smime-bks; Mon, 24 Jul 2000 13:09:04 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20176 for ; Mon, 24 Jul 2000 13:09:03 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA01435; Mon, 24 Jul 2000 13:12:01 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA01420; Mon, 24 Jul 2000 13:12:00 -0700 (PDT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com with ESMTP id NAA11729; Mon, 24 Jul 2000 13:12:34 -0700 (PDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20143 for ietf-smime-bks; Mon, 24 Jul 2000 13:07:17 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20139 for ; Mon, 24 Jul 2000 13:07:16 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA27660; Mon, 24 Jul 2000 13:10:11 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA27652; Mon, 24 Jul 2000 13:10:10 -0700 (PDT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com with ESMTP id NAA11048; Mon, 24 Jul 2000 13:10:45 -0700 (PDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for ; Mon, 24 Jul 2000 12:59:11 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for ietf-123-outbound.05@ietf.org; Mon, 24 Jul 2000 15:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for ; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Message-Id: <200007241038.GAA09375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt Date: Mon, 24 Jul 2000 06:38:44 -0400 List-Archive: List-ID: List-Unsubscribe: List-Archive: List-ID: List-Unsubscribe: List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-01.txt Pages : 55 Date : 21-Jul-00 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Jul 24 13:09:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20180 for ietf-smime-bks; Mon, 24 Jul 2000 13:09:04 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20176 for ; Mon, 24 Jul 2000 13:09:03 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA01435; Mon, 24 Jul 2000 13:12:01 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA01420; Mon, 24 Jul 2000 13:12:00 -0700 (PDT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com with ESMTP id NAA11729; Mon, 24 Jul 2000 13:12:34 -0700 (PDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20143 for ietf-smime-bks; Mon, 24 Jul 2000 13:07:17 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20139 for ; Mon, 24 Jul 2000 13:07:16 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA27660; Mon, 24 Jul 2000 13:10:11 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA27652; Mon, 24 Jul 2000 13:10:10 -0700 (PDT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com with ESMTP id NAA11048; Mon, 24 Jul 2000 13:10:45 -0700 (PDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for ; Mon, 24 Jul 2000 12:59:11 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for ietf-123-outbound.05@ietf.org; Mon, 24 Jul 2000 15:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for ; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Message-Id: <200007241038.GAA09375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt Date: Mon, 24 Jul 2000 06:38:44 -0400 List-Archive: List-ID: List-Unsubscribe: List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-01.txt Pages : 55 Date : 21-Jul-00 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Jul 24 13:07:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20143 for ietf-smime-bks; Mon, 24 Jul 2000 13:07:17 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20139 for ; Mon, 24 Jul 2000 13:07:16 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA27660; Mon, 24 Jul 2000 13:10:11 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA27652; Mon, 24 Jul 2000 13:10:10 -0700 (PDT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com with ESMTP id NAA11048; Mon, 24 Jul 2000 13:10:45 -0700 (PDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT) Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for ; Mon, 24 Jul 2000 12:59:11 -0700 (PDT) Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for ietf-123-outbound.05@ietf.org; Mon, 24 Jul 2000 15:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for ; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT) Message-Id: <200007241038.GAA09375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt Date: Mon, 24 Jul 2000 06:38:44 -0400 List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-01.txt Pages : 55 Date : 21-Jul-00 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Jul 25 03:35:27 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA08621 for ietf-smime-bks; Tue, 25 Jul 2000 03:35:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08611 for ; Tue, 25 Jul 2000 03:35:26 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24788; Tue, 25 Jul 2000 06:38:25 -0400 (EDT) Message-Id: <200007251038.GAA24788@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-ecc-01.txt Date: Tue, 25 Jul 2000 06:38:25 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Elliptic Curve S/MIME Author(s) : D. Brown Filename : draft-ietf-smime-ecc-01.txt Pages : 20 Date : 24-Jul-00 This document is the second draft of a profile for the incorporation of Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate message content. The definition of the algorithm processing is based on the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the ANSI X9F1 working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-ecc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-ecc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000724142646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-ecc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-ecc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724142646.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Jul 25 17:34:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA17195 for ietf-smime-bks; Tue, 25 Jul 2000 17:34:42 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17191 for ; Tue, 25 Jul 2000 17:34:41 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 25 Jul 2000 17:37:44 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: On requiring RSA (after September 20th, of course) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake Ramsdell has turned in two drafts that are worthy of consideration in this group. It's my opinion that they represent the reality of the marketplace, and that it would be good to have our RFCs reflect that if possible. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : S/MIME Version 3.1 Certificate Profile Addendum > Author(s) : B. Ramsdell > Filename : draft-ramsdell-smime31-cert-00.txt > Pages : > Date : 24-Jul-00 > >In light of the expiration of the primary RSA patent, it is proposed >that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST >implement algorithms in the S/MIME profile. This draft will describe >only the proposed changes to the S/MIME Version 3 Certificate Handling >RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ramsdell-smime31-cert-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ramsdell-smime31-cert-00.txt". >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : S/MIME Version 3.1 Message Specification Addendum > Author(s) : B. Ramsdell > Filename : draft-ramsdell-smime31-msg-00.txt > Pages : > Date : 24-Jul-00 > >In light of the expiration of the primary RSA patent, it is proposed >that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST >implement algorithms in the S/MIME profile. This draft will describe >only the proposed changes to the S/MIME Version 3 Message >Specification RFC [SMIMEV3MSG], and the rest of that RFC will remain >identical. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ramsdell-smime31-msg-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ramsdell-smime31-msg-00.txt". --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Jul 26 04:38:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA27142 for ietf-smime-bks; Wed, 26 Jul 2000 04:38:59 -0700 (PDT) Received: from mail1.commerzbank.com (mail1.commerzbank.com [193.158.252.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27138 for ; Wed, 26 Jul 2000 04:38:57 -0700 (PDT) Received: from sv004404.zdv.commerzbank.com (sv004404.cbkinternal.com [140.100.200.104]) by mail1.commerzbank.com (Postfix) with ESMTP id 64979156D70 for ; Wed, 26 Jul 2000 13:41:31 +0200 (CEST) Received: from sv016317.exchange.commerzbank.com (sv016317.exchange.commerzbank.com [140.100.200.214]) by sv004404.zdv.commerzbank.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA14014 for ; Wed, 26 Jul 2000 13:41:32 +0200 (METDST) Received: by SV016317 with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jul 2000 13:41:23 +0200 Message-ID: <6F539391E018D3119B570008C75D91E8BFB6D0@SV018442> From: "Baumgart, Ralf" To: "'ietf-smime@imc.org'" Subject: Some Questions to S/MIME Date: Wed, 26 Jul 2000 13:41:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear sirs, the Commerzbank, a big bank in Germany, is evaluating S/MIME. We were astonished that S/MIME V.3 became a proposed standard in July 1999. Now one year later nothing happens (on your imc-Web Sites). So our questions is, what could happened in the next six months: Will the proposed standard become a standard? What avtivities are proposed? with best regards ralf baumgart Commerzbank AG Abteilung ZIT P 3.53 Email/Web 60261 Frankfurt/Main Tel.:069-136-40448 email: ralf.baumgart@commee From owner-ietf-smime Wed Jul 26 07:25:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06227 for ietf-smime-bks; Wed, 26 Jul 2000 07:25:41 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06223 for ; Wed, 26 Jul 2000 07:25:40 -0700 (PDT) Received: from rhousley_laptop ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA00552; Wed, 26 Jul 2000 07:27:59 -0700 (PDT) Message-Id: <4.2.0.58.20000726101102.00a86250@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 26 Jul 2000 10:12:55 -0400 To: "Baumgart, Ralf" From: Russ Housley Subject: Re: Some Questions to S/MIME Cc: "'ietf-smime@imc.org'" In-Reply-To: <6F539391E018D3119B570008C75D91E8BFB6D0@SV018442> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ralf: I strongly disagree with your assessment. Important things are happening, perhaps not as quickly as we would all like, but they are happening. Most importantly, vendors are implementing! Major vendors have S/MIME products. Russ At 01:41 PM 07/26/2000 +0200, Baumgart, Ralf wrote: >Dear sirs, > >the Commerzbank, a big bank in Germany, is evaluating S/MIME. We were >astonished that S/MIME V.3 became a proposed standard in July 1999. Now one >year later nothing happens (on your imc-Web Sites). So our questions is, >what could happened in the next six months: Will the proposed standard >become a standard? What avtivities are proposed? > >with best regards >ralf baumgart >Commerzbank AG >Abteilung ZIT P 3.53 Email/Web >60261 Frankfurt/Main >Tel.:069-136-40448 >email: ralf.baumgart@commee From owner-ietf-smime Wed Jul 26 11:59:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA26723 for ietf-smime-bks; Wed, 26 Jul 2000 11:59:15 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26719 for ; Wed, 26 Jul 2000 11:59:14 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA07199; Wed, 26 Jul 2000 12:02:42 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 12:01:19 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBAA@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Baumgart, Ralf'" , "'ietf-smime@imc.org'" Subject: RE: Some Questions to S/MIME Date: Wed, 26 Jul 2000 12:01:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFF712.86137F80"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BFF712.86137F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The delay is not unusual and is a consequence of the IETF process and the IETF principle that standards should describe actual practice and implementation. Unlike other standards bodies, the IETF requires that implementations be deployed before recognizing a protocol as a 'standard'. Thus an IETF protocol typically becomes a standard some years AFTER it has been in common use. In the case of HTTP (the Web) this process took seven years. In other standards bodies development only starts after the standard has been fully agreed and approved. This approach is not a very good one since it is almost always desirable to modify the specification in the light of implementation experience. In essence the IETF approach is more like the Noble prizes, you get one after everyone has agreed that you have done the work and established a standard. The other body appears to regard agreement of standard as if it were the award of a building permit. The next significant event in the S/MIME standards track progress will be the promotion to Draft status. This is a highly technical process that involves a lot of input from implementors of the protocol. Before this can take place however all the standards that S/MIME references must also progress to draft standard status. In the meantime products based on the S/MIME v3 protocol and designed to interoperate with it are already available. In that sense S/MIME is quite clearly a 'standard' as the IETF defines it. Unfortunately it will take a while for the paperwork to catch up. Phill -----Original Message----- From: Baumgart, Ralf [mailto:Ralf.Baumgart@commerzbank.com] Sent: Wednesday, July 26, 2000 7:41 AM To: 'ietf-smime@imc.org' Subject: Some Questions to S/MIME Dear sirs, the Commerzbank, a big bank in Germany, is evaluating S/MIME. We were astonished that S/MIME V.3 became a proposed standard in July 1999. Now one year later nothing happens (on your imc-Web Sites). So our questions is, what could happened in the next six months: Will the proposed standard become a standard? What avtivities are proposed? with best regards ralf baumgart Commerzbank AG Abteilung ZIT P 3.53 Email/Web 60261 Frankfurt/Main Tel.:069-136-40448 email: ralf.baumgart@commee ------=_NextPart_000_0000_01BFF712.86137F80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcyNjE5MDIzMlowIwYJKoZI hvcNAQkEMRYEFJXcE1gSFQQ3pxGX7szVUJa9hr3UMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAScO58s1AZ0GjB+q/Gf1p7f3Skyf3oE6VrQKojesdkDdri6p7NedxT9lWlZ56kVku gMRoDk57VqcQy0GPDEBIvGUPbq7l7IEKje0FG3K3LUKR/3acErSjtPv05/BTpeh2rJ48mqXsJ2aA OQJq90UEkcQzNcQRJIftuC7aogVlJFQAAAAAAAA= ------=_NextPart_000_0000_01BFF712.86137F80-- From owner-ietf-smime Thu Jul 27 12:56:01 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA11137 for ietf-smime-bks; Thu, 27 Jul 2000 12:56:01 -0700 (PDT) Received: from mail.babylon.co.il ([194.90.80.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11133 for ; Thu, 27 Jul 2000 12:55:59 -0700 (PDT) From: officialpolltaker7@hotmail.com Received: from fw. ([194.90.80.209]) by mail.babylon.co.il (8.9.3/8.9.3) with SMTP id WAA14455; Thu, 27 Jul 2000 22:09:42 +0300 Received: from officialpolltaker8@hotmail.com by officialpolltaker7@hotmail.com (8.8.5/8.6.5) with SMTP id GAA05569 for ; Sat, 26 Jun 1999 04:51:25 -0600 (EST) Date: Sat, 26 Jun 99 04:51:25 EST To: officialpolltaker7@hotmail.com Subject: Enter The I Love/Hate SpamMail Opinion Poll -Pro Leads 3-1 Message-ID: Reply-To: officialpolltaker7@hotmail.com Comments: Authenticated sender is Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, A Poll is being taken to settle the issue whether commercial e-mail or SPAM is a good form of advertisement, which you would like more of or it's a bad form of advertisement which you are against. The arguments go more or less as follows: Pro: Commercial E-mail is a very efficient, cost effective means of informing people about new goods and services. This translates into substantial savings to the consumer. That the vast majority of internet users don't mind Spam and want to hear about new goods and services. That for Years now, more advanced bulk mailing software has allowed bulk mailers to shoulder the full cost of Spamming. This cost has increased and access has become much more difficult due to unfair and illegal practices by the big providers (the later day Robber Barons) Who have a vested interest in keeping Costs and Profits high for as long as possible, and with the news media with whom most have formed alliances, have and continue to wage a war of misinformation, deceptions, and out and out lies. That through an unholy alliance with vix.com, individuals and companies have been targeted by cyber terrorists who have attacked their equipment, programming and subjected people to threats of violence by posting personal information on these legitimate companies employees and individuals home addresses, phone numbers, which leads to threats against them, there families and children. Lastly, that the Robber Barons (Big Internet Providers) use special identification programs in their efforts to stop free trade that invades the privacy of all individuals by identifying, reading, and then determining whether or not you will get your mail or not (ask yourself this question, if AOL or SPRINT or AT&T or MicroSoftNetwork, (MSN), sent someone to your house to intercept your mail, open it, read it, and then arbitrarily decide whether they will put it in your mail box or not. Would you put up with that?) They call it filtering, we know it by its more insidious name, CENSORSHIP. Why in the world should you be subjected to this, and have to pay higher prices ! Anti SPAM: Anti Spam arguments go something like this: They don't like it. Some genuinely want to be isolated fromthe world, others it seems are simply being mislead. Spammers steal services and don't really pay for access, Spammers are evil because the big, rich, powerful, largeinternet service providers say so, and it's OK to targetthem for all kinds of bad things, legal or not. They don't like it. And would rather have themselves and consumers everywhere continue to pay high inflated pricesso that the Robber Barons may grow even richer and morepowerful. And finally, much like the Nazi's final solution to the Jewish problem, they are willing to act as the RobberBaron's Gestapo, ready to report for termination any Spammers or Spam sympathizers. SIMPLE SOLUTION: Press the delete key, STUPID ! Have a different opinion, give us a call because, your opinion on how to make this kind of advertisement better & to increase its use, is vital. Or if this is a terrible form of advertisement and how it should be curtailed, regulated or ended all together. Please call, 1-900-226-0388 and tell us. The charges for registering your opinion are as follows: Of the $1.99 per minute charge, 1-dollar goes to the telephone service Bureau 19 cents to retrieve your opinion 79 cents to transcribe this information into a viable format Leaving a total of 2 cents. So do call if you wish to get your 2 cents worth in ! Attention both Pro and Anti Spam Advocates and those of you who may have sought removal from any number of bulk mailing lists. If you have received this e-mail it is because it is a conscious decision on our part to try and include everyone in this important poll. To not have included those who profess a dislike for this form of advertisement would have eliminated those individuals from the process and provide an unfair advantage to one side of the poll. We sincerely hope that all interested individuals or entity's understand the necessity of inclusion. ******************************************************** This message is sent in compliance of the proposed bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident or otherwise wish to be removed from this list, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to mstrsrvcs@mailme.org with the word remove in the subject line. ********************************************************* 11-a-54 From owner-ietf-smime Sun Jul 30 15:14:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA09079 for ietf-smime-bks; Sun, 30 Jul 2000 15:14:36 -0700 (PDT) Received: from revelation (wireless-132-178.ietf.marconi.com [147.73.132.178]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA09070; Sun, 30 Jul 2000 15:14:32 -0700 (PDT) Reply-To: From: To: "Russ Housley \(E-mail\)" Cc: "Ietf-Smime \(E-mail\)" Subject: Comments on draft-ietf-smime-cms-rsaes-oaep-01.txt Date: Sun, 30 Jul 2000 18:02:57 -0400 Message-ID: <000001bffa74$091b7d10$b2844993@revelation> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200006221227.IAA27600@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 1 Paragraph 4: Spelling error on interactibe. Section 2 Paragraph 2: Remove last instance of "[CMS]" as it is not necessary. Section 2.1 Paragraph 3: Delete or reword this paragraph as it is not correct. originatorInfo may be present due to other recipient infos. Section 3 Paragraph 5 (maskGenFunc): MFG1 should be changed to MFG1SHA1 or all references to it using SHA1 should be replaced with references to it using a OWF. Section 3 Paragraph 5: Is SHA1 to be the one and only OWF supported here or are others permitted. Text is not clear on this issue. Section 3 Paragaraph 5 and 6: Why are you requiring that incorrectly encoded (i.e. the default value is supplied) be recognized? "... recognize both id-sha1 and absent..." Section 4 Paragraph 1: Spelling error "SEQUNCEs" Please add ASN module to the end. (I am just lazy.) jim schaad From owner-ietf-smime Tue Aug 1 06:02:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA27022 for ietf-smime-bks; Tue, 1 Aug 2000 06:02:56 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27012 for ; Tue, 1 Aug 2000 06:02:54 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA08365 for ; Tue, 1 Aug 2000 06:05:58 -0700 (PDT) Message-Id: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 31 Jul 2000 17:04:52 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Way Forward Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the face-to-face meeting today, we had a fair amount of discussion about the best way to proceed. This message states each of the issues and the proposed way forward. This message is intended to give everyone an opportunity to provide their input, even if they were unable to attend the meeting. RFC 2630 Interoperability Testing Issue: Two implementations have been tested for EnvelopedData and SignedData. These two data structures are required to implement S/MIME, so this is not surprising. RFC 2630 includes other data structure that are MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do not have two implementations for these data structures. Proposed way forward: Change the implementation requirements so that: - EnvelopedData and SignedData MUST be implemented; and - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented. Mandatory To Implement Algorithms Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested that the RSA algorithm become the mandatory to implement algorithm for key management and signature. It was pointed out that the current RSA key management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique should be employed instead. While we were discussing algorithms, it was suggested that AES should be the mandatory to implement symmetric cipher instead of Triple-DES. About half of the people thought that this was a good idea. The other half was concerned that the AES has not been published yet. Proposed way forward: Change the mandatory to implement algorithm set to: One-way Hash: SHA-1 (no change) Signature: Both DSA and RSA (PKCS#1 v1.5) Key Mgmt: RSA (OAEP) Eencryption: Triple-DES in CBC mode All comments on either of these proposals is most welcome. Russ From owner-ietf-smime Tue Aug 1 08:05:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03435 for ietf-smime-bks; Tue, 1 Aug 2000 08:05:05 -0700 (PDT) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03431 for ; Tue, 1 Aug 2000 08:05:04 -0700 (PDT) Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id IAA11694; Tue, 1 Aug 2000 08:08:41 -0700 (PDT) Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id IAA40722; Tue, 1 Aug 2000 08:11:34 -0700 (PDT) To: Russ Housley Cc: ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 01 Aug 2000 08:11:34 -0700 In-Reply-To: Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: > Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested > that the RSA algorithm become the mandatory to implement algorithm for key > management and signature. It was pointed out that the current RSA key > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique > should be employed instead. I'm not sure what the rationale is for this and it seems to me to present even more opportunities for incompatibility. The vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack that requires order 2^20 messages to be processed by the recipient with quite specific success or failure indications. In most applications, this isn't practical at all. Moreover, the attack is easily countered with a simple set of checks. -Ekr [Eric Rescorla ekr@rtfm.com] From owner-ietf-smime Tue Aug 1 09:25:23 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11246 for ietf-smime-bks; Tue, 1 Aug 2000 09:25:23 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11241 for ; Tue, 1 Aug 2000 09:25:22 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA08581 for ; Tue, 1 Aug 2000 12:16:05 -0400 (EDT) Message-Id: <200008011616.MAA08577@roadblock.missi.ncsc.mil> Date: Tue, 1 Aug 2000 12:24:46 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Way Forward To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uIo6sf+qiG6koAAVm4xnoA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Regarding data structures, http://www.ietf.org/ID-nits.html says: "For documents advancing in grade At least two complete, independent implementations must be tested and reported on, of each role (client/server/peer), and of each feature." I believe this implies that EncryptedData, DigestedData, and AuthenticatedData cannot be simply reduced to MAY status, but must be moved to a different document if RFC 2630 is to proceed to Draft. And attractive as it might be to require AES instead of 3DES, this clause precludes that option at this time. Regarding RSA, if OAEP is specified for RSA key transport, should not PSS be specified for signatures? That said, I agree with Erik that PKCS#1 v1.5 is sufficient for key transport, and if there are not two independent implementations of X9.31, PKCS#1 is probably sufficient for signatures. Regarding key establishment, I believe it would be good engineering to require a key agreement protocol such as DH, ECDH, a fully-public KEA, or a future FIPS key agreement algorithm in CMS-based systems, in addition to RSA key transport. If someone proposed that both RSA and X9.42 be mandatory, I would support that proposal if there were two tested implementations of X9.42. Are there? Regarding terminology, I suggest that the term "Key Establishment" be used in lieu of "Key Management" in RFC 2630 section 12.3 and elsewhere. OAEP and DH have very little to do with "managing" keys; they are used to establish a shared session key. See HAC Definition 12.2. Dave > Date: Mon, 31 Jul 2000 17:04:52 -0400 > To: ietf-smime@imc.org > From: Russ Housley > Subject: Way Forward > > At the face-to-face meeting today, we had a fair amount of discussion about > the best way to proceed. This message states each of the issues and the > proposed way forward. This message is intended to give everyone an > opportunity to provide their input, even if they were unable to attend the > meeting. > > RFC 2630 Interoperability Testing > > Issue: Two implementations have been tested for EnvelopedData and > SignedData. These two data structures are required to implement S/MIME, so > this is not surprising. RFC 2630 includes other data structure that are > MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do > not have two implementations for these data structures. > > Proposed way forward: Change the implementation requirements so that: > - EnvelopedData and SignedData MUST be implemented; and > - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented. > > Mandatory To Implement Algorithms > > Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested > that the RSA algorithm become the mandatory to implement algorithm for key > management and signature. It was pointed out that the current RSA key > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique > should be employed instead. While we were discussing algorithms, it was > suggested that AES should be the mandatory to implement symmetric cipher > instead of Triple-DES. About half of the people thought that this was a > good idea. The other half was concerned that the AES has not been > published yet. > > Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode > > All comments on either of these proposals is most welcome. > > Russ From owner-ietf-smime Tue Aug 1 10:56:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13082 for ietf-smime-bks; Tue, 1 Aug 2000 10:56:54 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13078 for ; Tue, 1 Aug 2000 10:56:53 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e71Hslj27458 for ; Tue, 1 Aug 2000 10:54:47 -0700 (PDT) Received: from netscape.com ([205.217.229.189]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FYMKNZ00.CJK; Tue, 1 Aug 2000 10:59:59 -0700 Message-ID: <3987101D.E762B110@netscape.com> Date: Tue, 01 Aug 2000 10:59:57 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: EKR CC: Russ Housley , ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with Eric. It would be better to maintain compatibility with the existing S/MIME v2 deployments by using the PKCS #1.5 version of RSA key management. If the vulnerability is the one Eric mentions, then it is not really significant. It relies on receiving a very specific error message that indicates that the PKCS #1.5 formatting was incorrect. It can be countered by including this error with other types of decryption errors (such as DES padding errors) or by allowing the decryption to proceed (with the wrong key) and signaling failures in the integrity (signature or authentication) portion of the message. Netscape's version of SSL does exactly this - the SSL handshake fails later in the sequence when the MAC calculation fails. In fact, in S/MIME it is not likely that the sender would any sort of response (error or otherwise) at all, which makes this attack impossible. In addition the requirement for 2^20 messages in an email environment makes it impractical as well. Again, I would like to see PKCS #1.5 included as the mandatory algorithm to allow compatibility with existing deployments. Terry Hayes thayes@netscape.com Eric Rescorla wrote: > Russ Housley writes: > > Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested > > that the RSA algorithm become the mandatory to implement algorithm for key > > management and signature. It was pointed out that the current RSA key > > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique > > should be employed instead. > I'm not sure what the rationale is for this and it seems to me to > present even more opportunities for incompatibility. The > vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack > that requires order 2^20 messages to be processed by the recipient > with quite specific success or failure indications. In most > applications, this isn't practical at all. Moreover, the attack is > easily countered with a simple set of checks. > > -Ekr > > [Eric Rescorla ekr@rtfm.com] From owner-ietf-smime Tue Aug 1 13:29:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16493 for ietf-smime-bks; Tue, 1 Aug 2000 13:29:55 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16489 for ; Tue, 1 Aug 2000 13:29:54 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA16726; Tue, 1 Aug 2000 13:32:59 -0700 (PDT) Message-Id: <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 01 Aug 2000 16:11:00 -0400 To: EKR From: Russ Housley Subject: Re: Way Forward Cc: ietf-smime@imc.org In-Reply-To: References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric: The attack is probably impossible to mount using S/MIME against a human-operated mail agent; however, I am not convinced that a mail list agent (or other automated mail agent) would be immune. Further, CMS is being used in many environments, not just S/MIME, and some of those environments may have issues. OAEP have been available for years. PKCS#1 v2.0 includes it. I do not think that it is immature. Russ At 08:11 AM 08/01/2000 -0700, Eric Rescorla wrote: >Russ Housley writes: > > Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested > > that the RSA algorithm become the mandatory to implement algorithm for key > > management and signature. It was pointed out that the current RSA key > > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique > > should be employed instead. >I'm not sure what the rationale is for this and it seems to me to >present even more opportunities for incompatibility. The >vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack >that requires order 2^20 messages to be processed by the recipient >with quite specific success or failure indications. In most >applications, this isn't practical at all. Moreover, the attack is >easily countered with a simple set of checks. > >-Ekr > >[Eric Rescorla ekr@rtfm.com] > > > > > From owner-ietf-smime Tue Aug 1 13:47:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16782 for ietf-smime-bks; Tue, 1 Aug 2000 13:47:13 -0700 (PDT) Received: from mdl.net (sfe02.mdl.net [195.22.225.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16778 for ; Tue, 1 Aug 2000 13:47:10 -0700 (PDT) Received: from 195.22.224.54 ([195.22.224.54]) by mdl.net with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 1 Aug 2000 23:50:09 +0300 Date: Tue, 1 Aug 2000 23:50:29 +0300 From: Maxim Masiutin X-Mailer: The Bat! (v1.46 Beta/2) Organization: RIT Research Labs X-Priority: 3 (Normal) Message-ID: <16611507687.20000801235029@ritlabs.com> To: Russ Housley , EKR , ietf-smime@imc.org, Eric Rescorla Subject: Re[2]: Way Forward In-reply-To: References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Russ! I'm an author of The Bat! http://www.ritlabs.com/the_bat/ This email client for Win32 that has S/MIME implementation based on own codebase written from scratch on Delphi as well as the rest of The Bat! I would like The Bat! to pass interoperability testing while forum continues. Your help would be appreciated. The Bat! official releases do not have S/MIME support yet, but beta versions of The Bat! are S/MIME enabled. You may download The Bat! with S/MIME support from http://www.ritlabs.com/the_bat/beta.html -- Maxim Masiutin, Software Engineer RIT Research Labs http://www.ritlabs.com/ From owner-ietf-smime Tue Aug 1 13:48:20 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16811 for ietf-smime-bks; Tue, 1 Aug 2000 13:48:20 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16807 for ; Tue, 1 Aug 2000 13:48:19 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA17112; Tue, 1 Aug 2000 13:50:51 -0700 (PDT) Message-Id: <4.2.0.58.20000801164313.00ad77b0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 01 Aug 2000 16:47:20 -0400 To: From: Russ Housley Subject: Re: Comments on draft-ietf-smime-cms-rsaes-oaep-01.txt Cc: ietf-smime@imc.org In-Reply-To: <000001bffa69$4ef5b9a0$b2844993@revelation> References: <200006221227.IAA27600@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: >Section 1 Paragraph 4: Spelling error on interactibe. Fixed. >Section 2 Paragraph 2: Remove last instance of "[CMS]" as it is not >necessary. Agree. >Section 2.1 Paragraph 3: Delete or reword this paragraph as it is not >correct. originatorInfo may be present due to other recipient infos. Agree. The originatorInfo may be present if some other recipient is using a different key management protocol. >Section 3 Paragraph 5 (maskGenFunc): MFG1 should be changed to MFG1SHA1 or >all references to it using SHA1 should be replaced with references to it >using a OWF. > >Section 3 Paragraph 5: Is SHA1 to be the one and only OWF supported here or >are others permitted. Text is not clear on this issue. Okay. >Section 3 Paragaraph 5 and 6: Why are you requiring that incorrectly >encoded (i.e. the default value is supplied) be recognized? "... recognize >both id-sha1 and absent..." This was done for alignment with PKCS#1 v2.0. >Section 4 Paragraph 1: Spelling error "SEQUNCEs" Fixed. >Please add ASN module to the end. (I am just lazy.) Will do. Either this draft will be folded into an algorithms document, or I will add a module here. Russ From owner-ietf-smime Tue Aug 1 14:12:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17228 for ietf-smime-bks; Tue, 1 Aug 2000 14:12:17 -0700 (PDT) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17224 for ; Tue, 1 Aug 2000 14:12:14 -0700 (PDT) Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id OAA28553; Tue, 1 Aug 2000 14:15:52 -0700 (PDT) Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA43065; Tue, 1 Aug 2000 14:18:46 -0700 (PDT) To: Russ Housley Cc: ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 01 Aug 2000 14:18:45 -0700 In-Reply-To: Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: > The attack is probably impossible to mount using S/MIME against a > human-operated mail agent; however, I am not convinced that a mail list > agent (or other automated mail agent) would be immune. Further, CMS is > being used in many environments, not just S/MIME, and some of those > environments may have issues. Understood, but it's trivial to patch these S/MIME agents to be completely immune to this attack without compromising compatibility. > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not > think that it is immature. That's not the issue that I am concerned with. Rather, I'm concerned with introducing gratuitous incompatibilities. -Ekr From owner-ietf-smime Tue Aug 1 14:45:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18157 for ietf-smime-bks; Tue, 1 Aug 2000 14:45:49 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18153 for ; Tue, 1 Aug 2000 14:45:48 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA18365; Tue, 1 Aug 2000 14:48:44 -0700 (PDT) Message-Id: <4.2.0.58.20000801174720.00a9e810@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 01 Aug 2000 17:47:51 -0400 To: Maxim Masiutin From: Russ Housley Subject: Re[2]: Way Forward Cc: ietf-smime@imc.org In-Reply-To: <16611507687.20000801235029@ritlabs.com> References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We would enjoy your participation. Russ At 11:50 PM 08/01/2000 +0300, Maxim Masiutin wrote: >Hello Russ! > > I'm an author of The Bat! > http://www.ritlabs.com/the_bat/ > > This email client for Win32 > > that has S/MIME implementation based on own codebase written from > scratch on Delphi as well as the rest of The Bat! > > I would like The Bat! to pass interoperability testing while forum > continues. Your help would be appreciated. > > The Bat! official releases do not have S/MIME support yet, but beta > versions of The Bat! are S/MIME enabled. > > You may download The Bat! with S/MIME support from > http://www.ritlabs.com/the_bat/beta.html > >-- >Maxim Masiutin, >Software Engineer >RIT Research Labs http://www.ritlabs.com/ > From owner-ietf-smime Tue Aug 1 15:57:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA19622 for ietf-smime-bks; Tue, 1 Aug 2000 15:57:56 -0700 (PDT) Received: from [207.155.230.112] (wireless-132-180.ietf.marconi.com [147.73.132.180]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19618 for ; Tue, 1 Aug 2000 15:57:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> Date: Tue, 1 Aug 2000 19:01:22 -0400 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Way Forward Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:18 PM -0700 8/1/00, Eric Rescorla wrote: > > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not >> think that it is immature. >That's not the issue that I am concerned with. Rather, I'm concerned >with introducing gratuitous incompatibilities. I'm with Eric on this one. We can add a note about how to avoid the problem *and* keep compatibility with the established S/MIME base. The proposal was prompted by S/MIME, not CMS. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Aug 2 05:42:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA03951 for ietf-smime-bks; Wed, 2 Aug 2000 05:42:15 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA03946 for ; Wed, 2 Aug 2000 05:42:14 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Aug 2000 12:45:34 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA28149 for ; Wed, 2 Aug 2000 08:44:27 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Wed, 2 Aug 2000 08:45:56 -0400 Message-ID: From: "Linn, John" To: ietf-smime@imc.org Subject: RE: Way Forward Date: Wed, 2 Aug 2000 08:45:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OAEP's incremental value is particularly applicable to interactive uses of CMS, many of which may not have S/MIME's established base concerns and which should take other protocol countermeasures (perhaps implying more security-relevant complexity and processing to be performed outside the bounds of the security encapsulation layer) if OAEP isn't applied. I'd like to recommend OAEP as at least a general SHOULD, making it the presumed mode unless an application has specific need to profile otherwise; if there's an S/MIME interoperability requirement for PKCS#1 v. 1.5, I'd suggest that the scope of that MUST's applicability be confined to the S/MIME application. --jl -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Tuesday, August 01, 2000 7:01 PM To: ietf-smime@imc.org Subject: Re: Way Forward At 2:18 PM -0700 8/1/00, Eric Rescorla wrote: > > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not >> think that it is immature. >That's not the issue that I am concerned with. Rather, I'm concerned >with introducing gratuitous incompatibilities. I'm with Eric on this one. We can add a note about how to avoid the problem *and* keep compatibility with the established S/MIME base. The proposal was prompted by S/MIME, not CMS. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Aug 2 08:18:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA13524 for ietf-smime-bks; Wed, 2 Aug 2000 08:18:11 -0700 (PDT) Received: from mail.telenisus.com (mail.tri-sage.com [204.248.55.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA13516 for ; Wed, 2 Aug 2000 08:18:10 -0700 (PDT) From: wnicolls@Telenisus.com X-Server-Uuid: ecb72b56-2dc3-11d2-bc91-002094082d29 Message-ID: <03E29E2A5833D411A5AC00508BC98E53218714@MAIN> To: ietf-smime@imc.org Subject: status of the Mapping Company Classification Policy to the S/MIME Security Label doc Date: Wed, 2 Aug 2000 10:26:34 -0500 MIME-Version: 1.0 X-WSS-ID: 1596E25132621-01-02 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry I was not at the meeting on Monday but airplane mechanical problems were my demise. Anyhow, please see the info below as this was my presentation material. The main area of work now is taking the security category syntax and working examples for each tag. But I am hoping to receive comments on the syntax (or any other area of the doc) as it is based on other work but is different. thanks, Weston Mapping Company Classification Policy to the S/MIME Security Label July 31, 2000 Purpose - Informational RFC - Build on Security Label feature defined in ESS - Show how Security Label can used to implement an organizational security policy Have - Classification Policies and OIDs for: Amoco Corporation General, Confidential, Highly Confidential Caterpillar Inc Public, Confidential Green, Confidential Yellow, Confidential Red Whirlpool Corporation Public, Internal, Confidential - Privacy Mark examples - Security Category syntax Need - Comments on 2nd draft - Generic S/MIME securityCategoryType OID <= request made for a SMIME oid for this - Security Category examples Security Category Syntax SecurityCategoryValues ::= SEQUENCE OF SecurityCategoryTagGroup SecurityCategoryTagGroup ::= SEQUENCE { securityCategoryTagGroupName OBJECT IDENTIFIER, <= request made for test Whirlpool OID securityCategoryTagGroup SEQUENCE OF SecurityCategoryTag} SecurityCategoryTag ::= CHOICE { restrictiveBitMap [0] BIT STRING, permissiveBitMap [1] BIT STRING, noAccessControlBitMap [2] BIT STRING, restrictiveEnumerated [3] SEQUENCE OF INTEGER, permissiveEnumerated [4] SEQUENCE OF INTEGER, noAccessControlEnumerated [5] SEQUENCE OF INTEGER} Restrictive Bit Map Tag Access must be restricted to only those messages whose set of attributes is a subset of the attributes for the message recipient. Security compartments and caveats are examples of restrictive security attributes. Permissive Bit Map Tag A message can be accepted if the recipient belongs to any of the release groups in the release permission list on the message label. For example, the label on entities to be available only to members of an organization's Personnel Office. No Access Control Bit Map Tag Represent security category values for which no access control check is required (e.g. originator controlled data) Restrictive Enumerated Tag Access must be restricted to only those messages whose set of attributes is a subset of the attributes for the recipient. An example of attributes enumerated by this tag are compartments. Permissive Enumerated Tag A message can be accepted if the recipient belongs to any of the release groups in the release permission list on the message label. An example of attributes enumerated by this tag are release permissions. No Access Control Enumerated Tag Represents security category values for which no access control check is required (e.g. list of country codes). 3rd Draft - fix errors, clarify wording as necessary - add examples as needed and marked now by << >> - address comments - September ? Weston Nicolls, CISSP Sr. Manager, Professional Services E-Commerce and Cryptography Telenisus Corporation - Managed Hosting, VPN, Authentication, Firewall and IDS Services (847) 871-5086 From owner-ietf-smime Wed Aug 2 08:28:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15836 for ietf-smime-bks; Wed, 2 Aug 2000 08:28:59 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15826 for ; Wed, 2 Aug 2000 08:28:57 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA28980; Wed, 2 Aug 2000 08:32:04 -0700 (PDT) Message-Id: <4.2.0.58.20000802111633.00aa6f00@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Aug 2000 11:20:39 -0400 To: EKR From: Russ Housley Subject: Re: Way Forward Cc: ietf-smime@imc.org In-Reply-To: References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric: I do not think that we are being gratuitous. I think that it is good security practice to remove any toe-hold that an attacker has. Further, I do not believe that the CMS layer in current S/MIME implementations exhibit the behavior (or lack thereof) necessary to be immune from the attack against RSA PKCS#1 v1.5. Russ At 02:18 PM 08/01/2000 -0700, Eric Rescorla wrote: >Russ Housley writes: > > The attack is probably impossible to mount using S/MIME against a > > human-operated mail agent; however, I am not convinced that a mail list > > agent (or other automated mail agent) would be immune. Further, CMS is > > being used in many environments, not just S/MIME, and some of those > > environments may have issues. >Understood, but it's trivial to patch these S/MIME agents to >be completely immune to this attack without compromising compatibility. > > > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not > > think that it is immature. >That's not the issue that I am concerned with. Rather, I'm concerned >with introducing gratuitous incompatibilities. > >-Ekr From owner-ietf-smime Wed Aug 2 08:38:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16784 for ietf-smime-bks; Wed, 2 Aug 2000 08:38:15 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16780 for ; Wed, 2 Aug 2000 08:38:14 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e72FWLA07342 for ; Wed, 2 Aug 2000 08:32:21 -0700 (PDT) Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FYO8X100.KYY; Wed, 2 Aug 2000 08:41:25 -0700 Message-ID: <3988411E.89719387@netscape.com> Date: Wed, 02 Aug 2000 08:41:18 -0700 From: relyea@netscape.com (Bob Relyea) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Russ Housley CC: EKR , ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> <4.2.0.58.20000802111633.00aa6f00@mail.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > Eric: > > I do not think that we are being gratuitous. I think that it is good > security practice to remove any toe-hold that an attacker has. Further, I > do not believe that the CMS layer in current S/MIME implementations exhibit > the behavior (or lack thereof) necessary to be immune from the attack > against RSA PKCS#1 v1.5. I have to agree with Eric here. Protocols where are *MUCH* more vulnerable than CMS or S/MIME were able to work around the attack. We know how to make out toolkits immune without sacrificing interoperability, we should do that. Current implementations that don't exhibit the correct behavior to be immune, still won't exhibit the correct behavior if you change the spec to OAEP. If we were developing a new protocol from the ground up, then using OAEP would be a no brainer. That is not the case here, though. bob From owner-ietf-smime Wed Aug 2 09:02:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17378 for ietf-smime-bks; Wed, 2 Aug 2000 09:02:05 -0700 (PDT) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17373 for ; Wed, 2 Aug 2000 09:02:03 -0700 (PDT) Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id JAA26361; Wed, 2 Aug 2000 09:05:44 -0700 (PDT) Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id JAA48337; Wed, 2 Aug 2000 09:08:38 -0700 (PDT) To: Russ Housley Cc: ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> <4.2.0.58.20000802111633.00aa6f00@mail.spyrus.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 02 Aug 2000 09:08:38 -0700 In-Reply-To: Russ Housley's message of "Wed, 02 Aug 2000 11:20:39 -0400" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: > I do not think that we are being gratuitous. I think that it is good > security practice to remove any toe-hold that an attacker has. Further, I > do not believe that the CMS layer in current S/MIME implementations exhibit > the behavior (or lack thereof) necessary to be immune from the attack > against RSA PKCS#1 v1.5. I'm sorry, Russ, but I don't understand your point. It's well known how to protect PKCS-1 implementations from this attack: If the PKCS-1 padding is wrong, instead of throwing an error you randomize the key and then continue. In fact, this is what essentially all SSL implementations do. While it may be the case that current S/MIME or CMS implementations don't do this, it's a trivial change to make and introduces no incompatibilities. Since adding OAEP also requires changing the code _and_ introduces incompatibilities, ISTM that just fixing one's PKCS-1 implementation is the dominant option. -Ekr From owner-ietf-smime Wed Aug 2 10:19:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19070 for ietf-smime-bks; Wed, 2 Aug 2000 10:19:45 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19066 for ; Wed, 2 Aug 2000 10:19:37 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA00763; Wed, 2 Aug 2000 13:17:36 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525692F.005EC4BF ; Wed, 2 Aug 2000 13:15:07 -0400 X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: Russ Housley cc: ietf-smime@imc.org Message-ID: <8525692F.005EC2B1.00@smtpmail.certicom.com> Date: Wed, 2 Aug 2000 13:12:14 -0400 Subject: Re: Way Forward Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, Several other groups within the IETF ... PKIX and TLS for example ... are separating their specifications into two documents ... one for data structures and one for algorithms. I think this should also be considered by the S/MIME group ... both because it is an elegant distinction which allows algorithms to be updated without affecting abstract structures, and because it may allow the structures document to proceed to standard more quickly in light of the mandatory algorithms issue. Best regards. Simon Russ Housley on 07/31/2000 05:04:52 PM To: ietf-smime@imc.org cc: (bcc: Simon Blake-Wilson/Certicom) Subject: Way Forward At the face-to-face meeting today, we had a fair amount of discussion about the best way to proceed. This message states each of the issues and the proposed way forward. This message is intended to give everyone an opportunity to provide their input, even if they were unable to attend the meeting. RFC 2630 Interoperability Testing Issue: Two implementations have been tested for EnvelopedData and SignedData. These two data structures are required to implement S/MIME, so this is not surprising. RFC 2630 includes other data structure that are MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do not have two implementations for these data structures. Proposed way forward: Change the implementation requirements so that: - EnvelopedData and SignedData MUST be implemented; and - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented. Mandatory To Implement Algorithms Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested that the RSA algorithm become the mandatory to implement algorithm for key management and signature. It was pointed out that the current RSA key management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique should be employed instead. While we were discussing algorithms, it was suggested that AES should be the mandatory to implement symmetric cipher instead of Triple-DES. About half of the people thought that this was a good idea. The other half was concerned that the AES has not been published yet. Proposed way forward: Change the mandatory to implement algorithm set to: One-way Hash: SHA-1 (no change) Signature: Both DSA and RSA (PKCS#1 v1.5) Key Mgmt: RSA (OAEP) Eencryption: Triple-DES in CBC mode All comments on either of these proposals is most welcome. Russ From owner-ietf-smime Wed Aug 2 10:20:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19086 for ietf-smime-bks; Wed, 2 Aug 2000 10:20:05 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19080 for ; Wed, 2 Aug 2000 10:20:00 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA00760; Wed, 2 Aug 2000 13:17:35 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525692F.005EC4EB ; Wed, 2 Aug 2000 13:15:07 -0400 X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: EKR cc: Russ Housley , ietf-smime@imc.org Message-ID: <8525692F.005EC2B2.00@smtpmail.certicom.com> Date: Wed, 2 Aug 2000 13:22:59 -0400 Subject: Re: Way Forward Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi folks, As Russ points out, there are applications of S/MIME where the known chosen ciphertext attack on PKCS 1 encryption is applicable. However I believe the more significant threat is that academic cryptographers have largely stopped looking at PKCS 1 encryption because they view it as broken from a theoretical viewpoint. I think this means that the risk that someone will come up with an improved attack (or already knows a better attack but is not publicizing it) is significant. I'd like to raise the opinions above as an objection to increasing the endorsement by the S/MIME WG of PKCS 1 encryption and would prefer to see the use of OAEP encouraged. Best regards. Simon Eric Rescorla on 08/01/2000 05:18:45 PM Please respond to EKR To: Russ Housley cc: ietf-smime@imc.org (bcc: Simon Blake-Wilson/Certicom) Subject: Re: Way Forward Russ Housley writes: > The attack is probably impossible to mount using S/MIME against a > human-operated mail agent; however, I am not convinced that a mail list > agent (or other automated mail agent) would be immune. Further, CMS is > being used in many environments, not just S/MIME, and some of those > environments may have issues. Understood, but it's trivial to patch these S/MIME agents to be completely immune to this attack without compromising compatibility. > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not > think that it is immature. That's not the issue that I am concerned with. Rather, I'm concerned with introducing gratuitous incompatibilities. -Ekr From owner-ietf-smime Wed Aug 2 11:24:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20375 for ietf-smime-bks; Wed, 2 Aug 2000 11:24:26 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20371 for ; Wed, 2 Aug 2000 11:24:24 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA00674; Thu, 3 Aug 2000 06:27:53 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96524087310105>; Thu, 3 Aug 2000 06:27:53 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: housley@spyrus.com, rescorla@mindspring.com Subject: Re: Way Forward Cc: ietf-smime@imc.org Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 3 Aug 2000 06:27:53 (NZST) Message-ID: <96524087310105@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >I do not think that we are being gratuitous. I think that it is good security >practice to remove any toe-hold that an attacker has. Further, I do not >believe that the CMS layer in current S/MIME implementations exhibit the >behavior (or lack thereof) necessary to be immune from the attack against RSA >PKCS#1 v1.5. When this topic came up the last time I posted the following summary of the situation: [...] this attack requires that an attacker send you around a million pieces of CMS encrypted email with attached receipt requests, that you respond with a million receipts indicating to the attacker the exact details of why the decrypt failed, that you reuse the same per-message key for each of those million messages. Now maybe I'm being a bit optimistic here, but I do think that claiming this is a weakness is a pretty silly. First of all you need to assume that an attacker can somehow send you a million pieces of email without you noticing and without it getting stopped by spam blockers. Your own software then has to try to decrypt each of the one million pieces of email, find that it can't, and send out a receipt to the sender containing an indication of exactly how the decryption failed (this isn't possible even if you wanted to do it, although who knows what the Receipt Notification WG have been working on recently). Finally, the whole attack only works if you reuse cryptovariables. This is why the CERT advisory on this problem specifically points out "This vulnerability does not affect S/MIME or SET". As a security threat, I'd say this rates somewhere down with "Router hit by meteorite", "Computer trampled by stampeding water buffalo", "Hard drive kidnapped by space aliens", and similar FUD. Sure, it is in theory possible, if you try really, really hard and are willing to bend over backwards to cooperate with an attacker, to allow this kind of attack to occur. However, abandoning a universally-implemented and used standard mechanism for a different one on the basis of something like this just doesn't make any sense. You're more likely to get someone's key by asking them for it (I've seen this happen a number of times, in some cases without even needing to ask for it, by people who assume that "PKCS #12 == certificate" and send out their "certificate" for others to use) than by using this kind of attack. Just because it's (theoretically) possible to break into Fort Knox with a can opener doesn't mean that Kentucky is going to start screening people at the border for possession of said item. Peter. From owner-ietf-smime Wed Aug 2 11:40:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20684 for ietf-smime-bks; Wed, 2 Aug 2000 11:40:58 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20680 for ; Wed, 2 Aug 2000 11:40:57 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA02593 for ; Wed, 2 Aug 2000 11:44:02 -0700 (PDT) Message-Id: <4.2.0.58.20000802143950.00ab9e10@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Aug 2000 14:43:27 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: RE: Way Forward In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would like to add that RFC 2630 states that future versions will support OAEP. It says (in the security considerations section): An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 Version 2.0 preserves support for the encryption padding format defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 Version 2.0 specifies and recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption is used to provide confidentiality. Designers of protocols and systems employing CMS for interactive environments should either consider usage of OAEP, or should ensure that information which could reveal the success or failure of attempted PKCS #1 Version 1.5 decryption operations is not provided. Support for OAEP will likely be added to a future version of the CMS specification. Russ At 08:45 AM 08/02/2000 -0400, Linn, John wrote: >OAEP's incremental value is particularly applicable to interactive uses of >CMS, many of which may not have S/MIME's established base concerns and which >should take other protocol countermeasures (perhaps implying more >security-relevant complexity and processing to be performed outside the >bounds of the security encapsulation layer) if OAEP isn't applied. I'd like >to recommend OAEP as at least a general SHOULD, making it the presumed mode >unless an application has specific need to profile otherwise; if there's an >S/MIME interoperability requirement for PKCS#1 v. 1.5, I'd suggest that the >scope of that MUST's applicability be confined to the S/MIME application. > >--jl > >-----Original Message----- >From: Paul Hoffman / IMC [mailto:phoffman@imc.org] >Sent: Tuesday, August 01, 2000 7:01 PM >To: ietf-smime@imc.org >Subject: Re: Way Forward > > >At 2:18 PM -0700 8/1/00, Eric Rescorla wrote: > > > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not > >> think that it is immature. > >That's not the issue that I am concerned with. Rather, I'm concerned > >with introducing gratuitous incompatibilities. > >I'm with Eric on this one. We can add a note about how to avoid the >problem *and* keep compatibility with the established S/MIME base. >The proposal was prompted by S/MIME, not CMS. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime Wed Aug 2 11:52:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20932 for ietf-smime-bks; Wed, 2 Aug 2000 11:52:04 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20924 for ; Wed, 2 Aug 2000 11:52:01 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e72Inxj28226 for ; Wed, 2 Aug 2000 11:49:59 -0700 (PDT) Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FYOHW000.85C; Wed, 2 Aug 2000 11:55:13 -0700 Message-ID: <39886E89.959DC634@netscape.com> Date: Wed, 02 Aug 2000 11:55:05 -0700 From: relyea@netscape.com (Bob Relyea) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Blake-Wilson CC: EKR , Russ Housley , ietf-smime@imc.org Subject: Re: Way Forward References: <8525692F.005EC2B2.00@smtpmail.certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Blake-Wilson wrote: > Hi folks, > > As Russ points out, there are applications of S/MIME where the known chosen > ciphertext attack > on PKCS 1 encryption is applicable. > > However I believe the more significant threat is that academic cryptographers > have largely > stopped looking at PKCS 1 encryption because they view it as broken from a > theoretical viewpoint. > I think this means that the risk that someone will come up with an improved > attack (or already knows > a better attack but is not publicizing it) is significant. Investigating other weaknesses in PKCS 1 is still of academic interest since several secure protocols which are widely deployed still use it, namely TLS and SSL. bob From owner-ietf-smime Wed Aug 2 13:15:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22659 for ietf-smime-bks; Wed, 2 Aug 2000 13:15:49 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22652 for ; Wed, 2 Aug 2000 13:15:48 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA04642; Wed, 2 Aug 2000 13:18:47 -0700 (PDT) Message-Id: <4.2.0.58.20000802155500.00ab1440@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Aug 2000 16:04:14 -0400 To: EKR , ietf-smime@imc.org From: Russ Housley Subject: Re: Way Forward In-Reply-To: References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> <4.2.0.58.20000802111633.00aa6f00@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric: One change or another is needed. Either we need to adopt OAEP or we need to include the correct processing steps for use with PKCS#1 v1.5. All: As chairman, I am trying to figure out the consensus of the work group. If everyone has enough information from this thread, then I would like to hear from folks that have an opinion but have not spoken up yet. Russ At 09:08 AM 08/02/2000 -0700, Eric Rescorla wrote: >Russ Housley writes: > > I do not think that we are being gratuitous. I think that it is good > > security practice to remove any toe-hold that an attacker has. Further, I > > do not believe that the CMS layer in current S/MIME implementations > exhibit > > the behavior (or lack thereof) necessary to be immune from the attack > > against RSA PKCS#1 v1.5. >I'm sorry, Russ, but I don't understand your point. It's well known >how to protect PKCS-1 implementations from this attack: If the PKCS-1 >padding is wrong, instead of throwing an error you randomize the key >and then continue. In fact, this is what essentially all SSL >implementations do. While it may be the case that current S/MIME or >CMS implementations don't do this, it's a trivial change to make and >introduces no incompatibilities. > >Since adding OAEP also requires changing the code _and_ introduces >incompatibilities, ISTM that just fixing one's PKCS-1 implementation >is the dominant option. > >-Ekr > From owner-ietf-smime Wed Aug 2 14:11:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23706 for ietf-smime-bks; Wed, 2 Aug 2000 14:11:19 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23702 for ; Wed, 2 Aug 2000 14:11:17 -0700 (PDT) Received: from [192.168.1.86] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FYO00JM8O7Y4B@mta6.snfc21.pbi.net> for ietf-smime@imc.org; Wed, 2 Aug 2000 14:11:59 -0700 (PDT) Date: Wed, 02 Aug 2000 14:12:04 -0700 From: Aram Perez Subject: Re: Way Forward In-reply-to: <4.2.0.58.20000802155500.00ab1440@mail.spyrus.com> To: ietf-smime@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, [snip] > > All: > > As chairman, I am trying to figure out the consensus of the work > group. If everyone has enough information from this thread, then I would > like to hear from folks that have an opinion but have not spoken up yet. My 2 centavos are: Keep PKCS#1.5 with appropriate notification on the known attack(s) and recommended procedures to minimize their effect. As you stated, there is already reference to OAEP for future versions. Regards, Aram Perez [snip] From owner-ietf-smime Wed Aug 2 14:35:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24126 for ietf-smime-bks; Wed, 2 Aug 2000 14:35:10 -0700 (PDT) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24122 for ; Wed, 2 Aug 2000 14:35:09 -0700 (PDT) Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id OAA00484; Wed, 2 Aug 2000 14:38:52 -0700 (PDT) Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA80155; Wed, 2 Aug 2000 14:41:45 -0700 (PDT) To: Russ Housley Cc: ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> <4.2.0.58.20000802111633.00aa6f00@mail.spyrus.com> <4.2.0.58.20000802155500.00ab1440@mail.spyrus.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 02 Aug 2000 14:41:45 -0700 In-Reply-To: Russ Housley's message of "Wed, 02 Aug 2000 16:04:14 -0400" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: > One change or another is needed. Either we need to adopt OAEP or we need > to include the correct processing steps for use with PKCS#1 v1.5. Agreed. I'm in favor of the latter, since they don't have any effect on compatibility. -Ekr From owner-ietf-smime Wed Aug 2 16:39:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26432 for ietf-smime-bks; Wed, 2 Aug 2000 16:39:01 -0700 (PDT) Received: from smtp.email.msn.com ([207.46.181.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26427 for ; Wed, 2 Aug 2000 16:39:00 -0700 (PDT) Received: from SSCSERVER1 - 63.10.61.34 by email.msn.com with Microsoft SMTPSVC; Wed, 2 Aug 2000 16:41:42 -0700 From: "John G Ross" To: Subject: RE: Way Forward Date: Thu, 3 Aug 2000 00:31:20 +0100 Message-ID: <000501bffcd9$c379deb0$a33f0a3f@SSCSERVER1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As backward compatability is only an issue between versions of S/MIME. Would a compromise be for CMS to keep to the existing mandatory algorithms as specified in RFC 2630 (DH/DSA), but in the message specification RFC 2633 also mandate support for RSA, for backward compatinility reasons with S/MIME v2. I know this means that both sets of algorithms have to be implemented in S/MIME, but is that really a big problem. Regards John Ross > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Aram Perez > Sent: Wednesday, August 02, 2000 10:12 PM > To: ietf-smime@imc.org > Subject: Re: Way Forward > > > Hi Russ, > > [snip] > > > > All: > > > > As chairman, I am trying to figure out the consensus of the work > > group. If everyone has enough information from this thread, > then I would > > like to hear from folks that have an opinion but have not spoken up yet. > > My 2 centavos are: Keep PKCS#1.5 with appropriate notification on > the known > attack(s) and recommended procedures to minimize their effect. As you > stated, there is already reference to OAEP for future versions. > > Regards, > Aram Perez > > [snip] > From owner-ietf-smime Wed Aug 2 17:49:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27462 for ietf-smime-bks; Wed, 2 Aug 2000 17:49:38 -0700 (PDT) Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27458 for ; Wed, 2 Aug 2000 17:49:36 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 13K9GC-0006CF-0Y for ietf-smime@imc.org; Thu, 3 Aug 2000 01:53:20 +0100 Message-ID: <3988C333.F8B74FC@celocom.com> Date: Thu, 03 Aug 2000 01:56:19 +0100 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <4.2.0.58.20000801160506.00a9d840@mail.spyrus.com> <4.2.0.58.20000802111633.00aa6f00@mail.spyrus.com> <4.2.0.58.20000802155500.00ab1440@mail.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > Eric: > > One change or another is needed. Either we need to adopt OAEP or we need > to include the correct processing steps for use with PKCS#1 v1.5. > > All: > > As chairman, I am trying to figure out the consensus of the work > group. If everyone has enough information from this thread, then I would > like to hear from folks that have an opinion but have not spoken up yet. > I'm in favour of keeping PKCS#1 v1.5 Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime Thu Aug 3 00:30:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21046 for ietf-smime-bks; Thu, 3 Aug 2000 00:30:01 -0700 (PDT) Received: from mail.brokat.de ([212.9.175.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21037 for ; Thu, 3 Aug 2000 00:29:57 -0700 (PDT) Received: by mail.brokat.de (Smail3.2.0.111/mail.brokat.de) via LF.net GmbH Internet Services via remoteip 172.17.6.61 via remotehost brokat.com with esmtp for mail.imc.org id m13KFWn-005lKdC; Thu, 3 Aug 2000 09:34:53 +0200 (CEST) Message-ID: <39892089.AE808CC5@brokat.com> Date: Thu, 03 Aug 2000 09:34:33 +0200 From: Malte Borcherding Organization: Brokat AG X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Russ Housley CC: Simon Blake-Wilson , ietf-smime@imc.org Subject: Re: Way Forward References: <8525692F.005EC2B1.00@smtpmail.certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I second Simon's proposal, an additional reason being that some specifications reuse the CMS syntax without mandating the same algorithms as CMS does. It would be easier and clearer to reference one specific CMS syntax document instead of saying "CMS, but just the data structures". Malte Simon Blake-Wilson wrote: > > Hi Russ, > > Several other groups within the IETF ... PKIX and TLS for example ... are > separating their specifications > into two documents ... one for data structures and one for algorithms. I think > this should also be > considered by the S/MIME group ... both because it is an elegant distinction > which allows algorithms > to be updated without affecting abstract structures, and because it may allow > the structures document > to proceed to standard more quickly in light of the mandatory algorithms issue. > > Best regards. Simon -- Malte Borcherding Brokat AG From owner-ietf-smime Thu Aug 3 09:01:37 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18748 for ietf-smime-bks; Thu, 3 Aug 2000 09:01:37 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18744 for ; Thu, 3 Aug 2000 09:01:36 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 12:04:53 -0400 Message-ID: From: Mike Just To: "'David P. Kemp'" , ietf-smime@imc.org Subject: Terminology - Was RE: Way Forward Date: Thu, 3 Aug 2000 12:02:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with David's suggestion below. I find it very confusing that the term "key management" is used here when I believe "key establishment" (or even "key agreement") would be more appropriate. When I hear key management, I think of updating keys in certificates. Key establishment is more closely related to what is actually occuring, and as David points out, is how it is defined in the literature. Mike J. > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Tuesday, August 01, 2000 12:25 PM > To: ietf-smime@imc.org > Subject: Re: Way Forward > <...snip...> > > Regarding terminology, I suggest that the term "Key Establishment" be > used in lieu of "Key Management" in RFC 2630 section 12.3 and > elsewhere. > OAEP and DH have very little to do with "managing" keys; they are used > to establish a shared session key. See HAC Definition 12.2. > > Dave > > From owner-ietf-smime Thu Aug 3 09:59:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19540 for ietf-smime-bks; Thu, 3 Aug 2000 09:59:12 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19536 for ; Thu, 3 Aug 2000 09:59:11 -0700 (PDT) Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA17245; Thu, 3 Aug 2000 10:02:21 -0700 (PDT) Message-Id: <4.2.0.58.20000803112005.00aa4d60@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 Aug 2000 11:29:04 -0400 To: "David P. Kemp" From: Russ Housley Subject: Re: Way Forward Cc: ietf-smime@imc.org In-Reply-To: <200008011616.MAA08577@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave: >Regarding data structures, http://www.ietf.org/ID-nits.html says: > > "For documents advancing in grade > > At least two complete, independent implementations must be tested and > reported on, of each role (client/server/peer), and of each feature." > >I believe this implies that EncryptedData, DigestedData, and >AuthenticatedData cannot be simply reduced to MAY status, but must be >moved to a different document if RFC 2630 is to proceed to Draft. I will discuss this with the Security ADs. >And >attractive as it might be to require AES instead of 3DES, this clause >precludes that option at this time. Given the flack associated with backward compatibility and OAEP, I will let you defend the AES. However, I think that AES with RSA-OAEP will be very attractive. >Regarding RSA, if OAEP is specified for RSA key transport, should not >PSS be specified for signatures? That said, I agree with Erik that >PKCS#1 v1.5 is sufficient for key transport, and if there are not two >independent implementations of X9.31, PKCS#1 is probably sufficient for >signatures. I am unaware of any security issues with PKCS#1 v1.5 RSA signatures. I am aware of the alternative format, but I do not know of any security reason to make a switch. >Regarding key establishment, I believe it would be good engineering to >require a key agreement protocol such as DH, ECDH, a fully-public KEA, >or a future FIPS key agreement algorithm in CMS-based systems, in >addition to RSA key transport. If someone proposed that both RSA and >X9.42 be mandatory, I would support that proposal if there were two >tested implementations of X9.42. Are there? I know of at least two Ephemeral-Static Diffie-Hellman implementations. I am not sure if any interoperability testing has been done. >Regarding terminology, I suggest that the term "Key Establishment" be >used in lieu of "Key Management" in RFC 2630 section 12.3 and elsewhere. >OAEP and DH have very little to do with "managing" keys; they are used >to establish a shared session key. See HAC Definition 12.2. Probably a good idea. I am not going to start a son-of-RFC2630 until we have a clear direction. Please remind me when the direction is clear. Russ From owner-ietf-smime Thu Aug 3 10:20:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20548 for ietf-smime-bks; Thu, 3 Aug 2000 10:20:22 -0700 (PDT) Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20544 for ; Thu, 3 Aug 2000 10:20:20 -0700 (PDT) Received: from dhcpdns.ietf.marconi.com (dhcpdns.ietf.marconi.com [147.73.128.3]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09165 for ; Thu, 3 Aug 2000 13:28:21 -0400 (EDT) Received: from ieca.com (wireless-134-53 [147.73.134.53]) by dhcpdns.ietf.marconi.com (8.9.3+Sun/8.9.1) with ESMTP id NAA00510 for ; Thu, 3 Aug 2000 13:27:38 -0400 (EDT) Message-ID: <3989AAAE.B076FED3@ieca.com> Date: Thu, 03 Aug 2000 13:23:58 -0400 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF S/MIME WG Subject: MUST vs. MAY in CMS specification Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAB9FABE777C1358ED6D419EA" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msAB9FABE777C1358ED6D419EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have to admit to some confusion over the claimed need to back the requirements for digested-data, encrypted-data, and authenticated-data from MUST to MAY. My reading of RFC 2630 suggests that they already are MAY, and neither are they used in the message spec (RFC 2633). Clause 2 of CMS is pretty clear in stating the conformance requirement for CMS. To wit: An implementation that conforms to this specification must implement the protection content, ContentInfo, and must implement the data, signed-data, and enveloped-data content types. The other content types may be implemented if desired. Can somebody explain where the supposed requirement to support these wrappers stems? Chris --------------msAB9FABE777C1358ED6D419EA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKIQYJKoZIhvcNAQcCoIIKEjCCCg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B+4wggS4MIIEIaADAgECAhACOZkTH5mWlYOiMWNS0NA/MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTIzMTAwMDAw MFoXDTAwMTIzMDIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxHDAaBgNVBAMUE0NocmlzdG9waGVyIEJvbmF0dGkxIDAe BgkqhkiG9w0BCQEWEWJvbmF0dGljQGllY2EuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB ANKXlrz4lCtsKxQPevEUJ59yPcZpDmBoZnivM/oJtD1bUq0uUPml8eaZThkLVb3lx5Y3bHMe iZUT86EDSuHBp78CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYL YIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCG SAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2 M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVh YzkzYmNhZmY4YTBiYWU2ZGY1ZDcxMTQ5OWJhMmI4NDRmOWYzZWE0NTA2MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEE BQADgYEAPEGSRUMcSfb9eE0h/Bqqe0Q6h0YgoqFEL7MCsCFC3QOwvgNROksoF2+dJOCnOGum vE3Pg6pyXJC02Qmt0qm2hmg3FLTNy0No9UnVld1NH0oejco+eeSfPO2xY0OFj1GojzeGZGfH hmhB1V43k1Be90B9i/Vn4Tw6UsnhIjg9NgMwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVd r+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1Yt xwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEG MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq hkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5 SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVga STyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAfswggH3AgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhACOZkTH5mWlYOiMWNS 0NA/MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDAwODAzMTcyMzU4WjAjBgkqhkiG9w0BCQQxFgQU+Jc0stRgjoITBkh/di+KWZFJ cvowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQMSMBWNk GkK0qBVOjIWxSKIqFnZGoYkSMbF8aJs0lQ2HuB7L8qfuQGCi0RNH80EhvI716d2C0wGaTlDg 8TBBYrY= --------------msAB9FABE777C1358ED6D419EA-- From owner-ietf-smime Thu Aug 3 11:37:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA22405 for ietf-smime-bks; Thu, 3 Aug 2000 11:37:58 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22400 for ; Thu, 3 Aug 2000 11:37:57 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 14:47:23 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D021A@wfhqex01.wangfed.com> From: "Pawling, John" To: ietf-smime@imc.org Subject: RE: Way Forward Date: Thu, 3 Aug 2000 14:41:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Your message stated: "RFC 2630 includes other data structure that are MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do not have two implementations for these data structures." RFC 2630, Section 2, General Overview, states: "An implementation that conforms to this specification must implement the protection content, ContentInfo, and must implement the data, signed-data, and enveloped-data content types. The other content types may be implemented if desired." Therefore, the EncryptedData, DigestedData and AuthenticatedData content types are already "MAY implement" requirements (not "MUST implement" requirements). FYI. The S/MIME Freeware Library (SFL) implements the EncryptedData content type. Wang Government Services has not successfully performed interoperability testing of the EncryptedData content type between the SFL and any other implementations. We did use the SFL to create an example EncryptedData object with unprotected attributes that we sent to Paul Hoffman for inclusion in the "Examples of S/MIME Messages" Internet-Draft. We are willing to participate in interop testing with anyone else who has implemented the EncryptedData content type. The SFL does not implement the DigestedData and AuthenticatedData content types. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-ietf-smime Thu Aug 3 11:42:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA22474 for ietf-smime-bks; Thu, 3 Aug 2000 11:42:29 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22469 for ; Thu, 3 Aug 2000 11:42:28 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 14:51:54 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D021B@wfhqex01.wangfed.com> From: "Pawling, John" To: ietf-smime@imc.org Subject: RE: Way Forward Date: Thu, 3 Aug 2000 14:45:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ/Dave, When used in conjunction with the Crypto++ freeware library, the S/MIME Freeware Library (SFL) implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. Wang Government Services has successfully performed interop testing of Ephemeral-Static (E-S) D-H-protected envelopedData objects between the SFL and Microsoft. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-ietf-smime Thu Aug 3 13:10:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA23819 for ietf-smime-bks; Thu, 3 Aug 2000 13:10:25 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23814 for ; Thu, 3 Aug 2000 13:10:23 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id IAA28418; Fri, 4 Aug 2000 08:13:58 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96533363803094>; Fri, 4 Aug 2000 08:13:58 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: John.Pawling@wang.com, ietf-smime@imc.org Subject: RE: Way Forward Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 4 Aug 2000 08:13:58 (NZST) Message-ID: <96533363803094@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Pawling, John" writes: >The S/MIME Freeware Library (SFL) implements the EncryptedData content type. >Wang Government Services has not successfully performed interoperability >testing of the EncryptedData content type between the SFL and any other >implementations. We did use the SFL to create an example EncryptedData object >with unprotected attributes that we sent to Paul Hoffman for inclusion in the >"Examples of S/MIME Messages" Internet-Draft. We are willing to participate in >interop testing with anyone else who has implemented the EncryptedData content >type. I've done EncryptedData (it's a trivial subset of EnvelopedData), here's a sample encrypted with CAST-128 using the key "0123456789ABCDEF": begin 644 EncryptedData.der M,$X&"2J&2(;W#0$'!J!!,#\"`0`P.@8)*H9(AO<-`0The SFL does not implement the DigestedData and AuthenticatedData content >types. Ditto. My position on these is that I'll implement them as soon as someone requests them. OTOH I've only had the code out there for about two years, so the stampede might start at any point :-). Peter. From owner-ietf-smime Thu Aug 3 14:57:43 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA02307 for ietf-smime-bks; Thu, 3 Aug 2000 14:57:43 -0700 (PDT) Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02293 for ; Thu, 3 Aug 2000 14:57:41 -0700 (PDT) Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA22508; Thu, 3 Aug 2000 18:01:23 -0400 (EDT) Message-ID: <3989EB28.2CD2F345@ieca.com> Date: Thu, 03 Aug 2000 17:59:04 -0400 From: Sean Turner Organization: IECA, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org CC: Russ Housley Subject: Re: Way Forward References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My two cents: I think it's likely that we'll switch to AES when it's finalized, why don't we wait to change until then? Then we only have to change once. Cheers, spt Russ Housley wrote: > At the face-to-face meeting today, we had a fair amount of discussion about > the best way to proceed. This message states each of the issues and the > proposed way forward. This message is intended to give everyone an > opportunity to provide their input, even if they were unable to attend the > meeting. > > RFC 2630 Interoperability Testing > > Issue: Two implementations have been tested for EnvelopedData and > SignedData. These two data structures are required to implement S/MIME, so > this is not surprising. RFC 2630 includes other data structure that are > MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do > not have two implementations for these data structures. > > Proposed way forward: Change the implementation requirements so that: > - EnvelopedData and SignedData MUST be implemented; and > - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented. > > Mandatory To Implement Algorithms > > Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested > that the RSA algorithm become the mandatory to implement algorithm for key > management and signature. It was pointed out that the current RSA key > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique > should be employed instead. While we were discussing algorithms, it was > suggested that AES should be the mandatory to implement symmetric cipher > instead of Triple-DES. About half of the people thought that this was a > good idea. The other half was concerned that the AES has not been > published yet. > > Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode > > All comments on either of these proposals is most welcome. > > Russ From owner-ietf-smime Thu Aug 3 15:59:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA03848 for ietf-smime-bks; Thu, 3 Aug 2000 15:59:02 -0700 (PDT) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03844 for ; Thu, 3 Aug 2000 15:58:59 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 13KU0l-000LRS-0V for ietf-smime@imc.org; Fri, 4 Aug 2000 00:02:48 +0100 Message-ID: <3989FA6E.8F7BE8C9@celocom.com> Date: Fri, 04 Aug 2000 00:04:14 +0100 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: Way Forward References: <4B0D36365AD3D2118FF40060972A16C0016D021B@wfhqex01.wangfed.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Re RFC2631. I've only seen one example of the parameter generation technique RFC2631 2.2.1 which is part of the examples draft. However it doesn't agree with my (experimental) version. Despite queries in various groups I've so far been unable to locate anyone who can supply alternative test vectors that are not equivalent to the FIPS-186 (DSS) special case (the X9.42. spec itself only has DSS compatible examples) Most people seem to be using alternative techniques. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime Fri Aug 4 06:10:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA03281 for ietf-smime-bks; Fri, 4 Aug 2000 06:10:24 -0700 (PDT) Received: from [147.73.132.180] (ts003d48.haz-mo.concentric.net [207.155.230.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03272 for ; Fri, 4 Aug 2000 06:10:20 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3989EB28.2CD2F345@ieca.com> References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> <3989EB28.2CD2F345@ieca.com> Date: Fri, 4 Aug 2000 09:12:05 -0400 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Way Forward Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:59 PM -0400 8/3/00, Sean Turner wrote: >My two cents: I think it's likely that we'll switch to AES when >it's finalized, why >don't we wait to change until then? Then we only have to change once. It sounds like we need to better define our goals for changing the current RFCs. My goal is to have it reflect the reality of today's deployed base of S/MIME MUAs. Because of that, mandating either OEAP or AES would be much worse than leaving the current RFCs alone. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri Aug 4 12:23:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21391 for ietf-smime-bks; Fri, 4 Aug 2000 12:23:19 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21387 for ; Fri, 4 Aug 2000 12:23:18 -0700 (PDT) Received: from rhousley_laptop (216-164-131-174.s174.tnt2.lnhva.md.dialup.rcn.com [216.164.131.174]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA06250; Fri, 4 Aug 2000 12:26:31 -0700 (PDT) Message-Id: <4.2.0.58.20000804151934.00aa5ba0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 04 Aug 2000 15:19:55 -0400 To: "Bonatti, Chris" From: Russ Housley Subject: Re: MUST vs. MAY in CMS specification Cc: IETF S/MIME WG In-Reply-To: <3989AAAE.B076FED3@ieca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris: I guess we had more foresight that I remembered.... Russ At 01:23 PM 08/03/2000 -0400, Bonatti, Chris wrote: > I have to admit to some confusion over the claimed need to >back the requirements for digested-data, encrypted-data, and >authenticated-data from MUST to MAY. My reading of RFC 2630 >suggests that they already are MAY, and neither are they used in >the message spec (RFC 2633). Clause 2 of CMS is pretty clear in >stating the conformance requirement for CMS. To wit: > > An implementation that conforms to this specification > must implement the protection content, ContentInfo, and > must implement the data, signed-data, and > enveloped-data content types. The other content types > may be implemented if desired. > >Can somebody explain where the supposed requirement to support >these wrappers stems? > >Chris From owner-ietf-smime Tue Aug 8 09:36:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11340 for ietf-smime-bks; Tue, 8 Aug 2000 09:36:24 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11336 for ; Tue, 8 Aug 2000 09:36:23 -0700 (PDT) Received: from rhousley_laptop ([209.172.119.201]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA20231; Tue, 8 Aug 2000 09:40:02 -0700 (PDT) Message-Id: <4.2.0.58.20000808123523.00acb490@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Aug 2000 12:39:01 -0400 To: From: Russ Housley Subject: RE: Way Forward Cc: ietf-smime@imc.org In-Reply-To: <003401c0013f$cefb0a60$01fea8c0@btinteractive.net> References: <4.2.0.58.20000731160150.00aa18f0@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: We encourage additional implementations to participate in the interoperability testing. I understand the concern that you raise about changes in the mandatory-to-implement algorithms. This is why we are having a discussion before any action is taken. Other implementors support RSA and do not support D-H. These folks would like to see S/MIME v2 and S/MIME v3 have an interoperable mandatory-to-implement algorithm. Russ At 02:51 PM 08/08/2000 +0100, Jim Davies wrote: >Hi Russ > >I am a recipient of the mailings in this group - as someone with limited >technical knowledge but a business interest in PKI - and S/MIME 3 standards >in particular. Please make allowances therefore if any of my questions or >comments are totally off beam! > >I have been following the discussions prompted by the proposals below on RFC >2630 - and also trying to tie them in with RFC 2632: S/MIME Version 3 >Certificate handling - and RFC 2633: S/MIME Version 3 Message specification. > >My project is currently based around a mail product called Reflex MailSafe >(http://www.reflex-magnetics.com). It offers full S/MIME 3 compatibility >and can use either DH or RSA for generating key pairs. A "cut down" 56 bit >version is available at the web site - other than key length it is fully >functional. At present there is only a mail client - in due course it is >planned to offer various network features. > >To my mind - the use of DH keys is preferable to RSA. I had assumed that - >as a result of using DH keys - S/MIME 2 products would not be able to read >S/MIME 3 encrypted - and DSA signed - messages. > >I am concerned that what appears to be happening is a downgrading or >watering down of S/MIME 3 in order to enable interoperability with S/MIME 2 >products. It seems particularly curious when there is a mail client >available that - so far as I can tell - provides the previously stated >functionality. I need to be able to make sound business planning >decisions - and this debate has thrown me into a bit of a spin. > >Am I mis-reading what appears to be going on - or do I have a genuine need >to re-consider my planning? Also - were you aware of Reflex MailSafe - >which I believe to be the first product available that offers full S/MIME 3 >compatibility? If not - does any of the above have any impact on the >proposed changes to the standards? > >As I said at the outset - please disabuse me if I have missed the point here >completely - much of what is discussed quite frankly goes over my head! > >I look forward to hearing from you. > >Best wishes > >Jim > >Jim Davies >Director - GPM Ltd. >82 Dartmouth Park Hill >London N19 5HU > >Tel. +44 (0) 20 72810123 >Fax +44 (0) 20 75611666 >Mobile +44 (0)7958 523479 >Email JimDavies@gpm.co.uk > > >This e-mail transmission (and any attachment) is strictly confidential >and intended solely for the person or organisation to whom it is >addressed. It may contain privileged and confidential information and >if you are not the intended recipient, you must not copy, distribute or >take any action in reliance on it. If you have received this e-mail in >error, please notify us as soon as possible and delete it. > > > > > >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Russ Housley >Sent: 31 July 2000 22:05 >To: ietf-smime@imc.org >Subject: Way Forward > > >At the face-to-face meeting today, we had a fair amount of discussion about >the best way to proceed. This message states each of the issues and the >proposed way forward. This message is intended to give everyone an >opportunity to provide their input, even if they were unable to attend the >meeting. > >RFC 2630 Interoperability Testing > >Issue: Two implementations have been tested for EnvelopedData and >SignedData. These two data structures are required to implement S/MIME, so >this is not surprising. RFC 2630 includes other data structure that are >MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do >not have two implementations for these data structures. > >Proposed way forward: Change the implementation requirements so that: > - EnvelopedData and SignedData MUST be implemented; and > - EncryptedData, DigestedData, and AuthenticatedData MAY be > implemented. > >Mandatory To Implement Algorithms > >Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested >that the RSA algorithm become the mandatory to implement algorithm for key >management and signature. It was pointed out that the current RSA key >management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique >should be employed instead. While we were discussing algorithms, it was >suggested that AES should be the mandatory to implement symmetric cipher >instead of Triple-DES. About half of the people thought that this was a >good idea. The other half was concerned that the AES has not been >published yet. > >Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode > >All comments on either of these proposals is most welcome. > >Russ From owner-ietf-smime Tue Aug 8 10:03:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12002 for ietf-smime-bks; Tue, 8 Aug 2000 10:03:36 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11998 for ; Tue, 8 Aug 2000 10:03:34 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA09876 for ; Tue, 8 Aug 2000 12:54:04 -0400 (EDT) Message-Id: <200008081654.MAA09871@roadblock.missi.ncsc.mil> Date: Tue, 8 Aug 2000 13:03:17 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Way Forward To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ijlAkIyPVznwibtgOw2Uew== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that the mandatory algorithms should not be specified in CMS, for exactly this reason. The message specification is a reasonable place for S/MIME algorithm requirements. Other CMS-using applications will have their own requirements. Dave > From: Malte Borcherding > > I second Simon's proposal, an additional reason being that some specifications > reuse the CMS syntax without mandating the same algorithms as CMS does. It would > be easier and clearer to reference one specific CMS syntax document instead of > saying "CMS, but just the data structures". > > Malte > > Simon Blake-Wilson wrote: > > > > Hi Russ, > > > > Several other groups within the IETF ... PKIX and TLS for example ... are > > separating their specifications > > into two documents ... one for data structures and one for algorithms. I think > > this should also be > > considered by the S/MIME group ... both because it is an elegant distinction > > which allows algorithms > > to be updated without affecting abstract structures, and because it may allow > > the structures document > > to proceed to standard more quickly in light of the mandatory algorithms issue. From owner-ietf-smime Tue Aug 8 13:37:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA15747 for ietf-smime-bks; Tue, 8 Aug 2000 13:37:15 -0700 (PDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15743 for ; Tue, 8 Aug 2000 13:37:12 -0700 (PDT) Received: from [212.140.201.204] (helo=Jim) by tungsten.btinternet.com with smtp (Exim 3.03 #83) id 13MGBQ-00025B-00; Tue, 08 Aug 2000 21:41:08 +0100 Reply-To: From: "Jim Davies" To: "Russ Housley" Cc: Subject: RE: Way Forward Date: Tue, 8 Aug 2000 21:05:27 +0100 Message-ID: <003c01c00173$ff62b660$01fea8c0@btinteractive.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <4.2.0.58.20000808123523.00acb490@mail.spyrus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Glad to get involved. Unless I am missing a trick - Reflex MailSafe implements both RSA and D-H - which enables it to be both backward compatible if dealing with mail from S/MIME v2 users and forward compatible for S/MIME v3. My question was really - unless I am missing the point - why therefore dilute the S/MIME v3 standard? Best wishes Jim -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: 08 August 2000 17:39 To: JimDavies@sedox.com Cc: ietf-smime@imc.org Subject: RE: Way Forward Jim: We encourage additional implementations to participate in the interoperability testing. I understand the concern that you raise about changes in the mandatory-to-implement algorithms. This is why we are having a discussion before any action is taken. Other implementors support RSA and do not support D-H. These folks would like to see S/MIME v2 and S/MIME v3 have an interoperable mandatory-to-implement algorithm. Russ At 02:51 PM 08/08/2000 +0100, Jim Davies wrote: >Hi Russ > >I am a recipient of the mailings in this group - as someone with limited >technical knowledge but a business interest in PKI - and S/MIME 3 standards >in particular. Please make allowances therefore if any of my questions or >comments are totally off beam! > >I have been following the discussions prompted by the proposals below on RFC >2630 - and also trying to tie them in with RFC 2632: S/MIME Version 3 >Certificate handling - and RFC 2633: S/MIME Version 3 Message specification. > >My project is currently based around a mail product called Reflex MailSafe >(http://www.reflex-magnetics.com). It offers full S/MIME 3 compatibility >and can use either DH or RSA for generating key pairs. A "cut down" 56 bit >version is available at the web site - other than key length it is fully >functional. At present there is only a mail client - in due course it is >planned to offer various network features. > >To my mind - the use of DH keys is preferable to RSA. I had assumed that - >as a result of using DH keys - S/MIME 2 products would not be able to read >S/MIME 3 encrypted - and DSA signed - messages. > >I am concerned that what appears to be happening is a downgrading or >watering down of S/MIME 3 in order to enable interoperability with S/MIME 2 >products. It seems particularly curious when there is a mail client >available that - so far as I can tell - provides the previously stated >functionality. I need to be able to make sound business planning >decisions - and this debate has thrown me into a bit of a spin. > >Am I mis-reading what appears to be going on - or do I have a genuine need >to re-consider my planning? Also - were you aware of Reflex MailSafe - >which I believe to be the first product available that offers full S/MIME 3 >compatibility? If not - does any of the above have any impact on the >proposed changes to the standards? > >As I said at the outset - please disabuse me if I have missed the point here >completely - much of what is discussed quite frankly goes over my head! > >I look forward to hearing from you. > >Best wishes > >Jim > >Jim Davies >Director - GPM Ltd. >82 Dartmouth Park Hill >London N19 5HU > >Tel. +44 (0) 20 72810123 >Fax +44 (0) 20 75611666 >Mobile +44 (0)7958 523479 >Email JimDavies@gpm.co.uk > > >This e-mail transmission (and any attachment) is strictly confidential >and intended solely for the person or organisation to whom it is >addressed. It may contain privileged and confidential information and >if you are not the intended recipient, you must not copy, distribute or >take any action in reliance on it. If you have received this e-mail in >error, please notify us as soon as possible and delete it. > > > > > >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Russ Housley >Sent: 31 July 2000 22:05 >To: ietf-smime@imc.org >Subject: Way Forward > > >At the face-to-face meeting today, we had a fair amount of discussion about >the best way to proceed. This message states each of the issues and the >proposed way forward. This message is intended to give everyone an >opportunity to provide their input, even if they were unable to attend the >meeting. > >RFC 2630 Interoperability Testing > >Issue: Two implementations have been tested for EnvelopedData and >SignedData. These two data structures are required to implement S/MIME, so >this is not surprising. RFC 2630 includes other data structure that are >MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do >not have two implementations for these data structures. > >Proposed way forward: Change the implementation requirements so that: > - EnvelopedData and SignedData MUST be implemented; and > - EncryptedData, DigestedData, and AuthenticatedData MAY be > implemented. > >Mandatory To Implement Algorithms > >Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested >that the RSA algorithm become the mandatory to implement algorithm for key >management and signature. It was pointed out that the current RSA key >management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique >should be employed instead. While we were discussing algorithms, it was >suggested that AES should be the mandatory to implement symmetric cipher >instead of Triple-DES. About half of the people thought that this was a >good idea. The other half was concerned that the AES has not been >published yet. > >Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode > >All comments on either of these proposals is most welcome. > >Russ From owner-ietf-smime Thu Aug 10 14:48:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16134 for ietf-smime-bks; Thu, 10 Aug 2000 14:48:11 -0700 (PDT) Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16128 for ; Thu, 10 Aug 2000 14:48:10 -0700 (PDT) Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA12949 for ; Thu, 10 Aug 2000 17:47:24 -0400 (EDT) Message-ID: <39932261.AF57D303@ieca.com> Date: Thu, 10 Aug 2000 17:45:05 -0400 From: Sean Turner Organization: IECA, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: SMIME Subject: Comments on symkeydist-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Here are the comments I've received off-line on the symmetric key distribution draft: General: - Remove distributionMethod from messages. Whatever mechanism the GLA supports is the mechanism the objects will be distributed to the GL members. - CMC expects a one-to-one relationship between control messages and responses. glAddMembers, glRemoveMembers, glAddOwners, glRemoveOwners should only support adding/removing one member/owner at a time. glSuccessInfo and glFailInfo will also need to be changed accordingly. - In section 4, glIdentifier is optional determining whether the GL is supported by the GLA. Since the glName has to be unique for a given GLA, the glName should be used to determine whether the GL is supported by the GLA. Remove glIdentifier from glDelete, glAddMembers, glDeleteMembers, glAddOwner, glDeleteOwner, glKeyCompromise, and glKeyRefresh. - glDelete, glAddOwners, glRemoveOwners, glkCompromise, and glkRefresh have an unneeded layer of indirection. Please remove (e.g., GLDelete ::= GLNameAndIdentifier just make glDelete be GeneralName). Para 1.1: - Explicitly state that the the originator can use either the shared KEK or the MLA's public key certificate to encrypt messages for the MLA. Para 2 1st para below Figure 1 - The method of key archival would be a better way to differentiate between multiple KMAs that support a single GLA. Para 3.1 - A message to request old shared KEKs should be added. This would allow new GL members to access messages encrypted under old KEKs. It would support things such as list archives. - A message for the GL member to indicate that they have a new PKC should be added. This would help in distribution of messages. - A message for the GLO to ask GL members for new certificates should be added. This will help when the GL member's certificate has expired or is revoked. - Need to provide context for implementation column - what component needs to implement what messages. - Use lower case names to refer to the messages (i.e., glUseKEK vice GLUseKEK). para 3.1.1 - glUseKEK - You defaulted everything but requestedAlgorithm - make default algorithm 3DES. - The default for glAdministration should be managed and accepts requests. It seems strange to default secure group lists to be "open." para 3.1.3 & 3.1.4 glAddMembers and glDeleteMembers - Indicate in the first paragraph that the message must be signed by the GLO or GL member. para 3.1.5 glRekey - Remove glOwner from the message. There should be one mechanism to change the GL owner and that's glAddOwner. - Not sure if the defaulting mechanism in para 3.1.6 glAddOwner - The gLAddOwner message is applicable to closed lists also. There is still one owner, but when a GLO leaves a company, for example, there has to be a mechanism to replace the old GLO with a new GLO. para 3.1.8 glKeyCompromise - Somewhere in the draft there is a statement that only the GLO or the GLA can generate rekey messages. paragraph 4 indicates that if this message is sent to the GLA by a GL member it initiates a rekey. The message should be redirected to the GLO to maintain this model. 3.1.10 & 3.1.11 glSucessInfo and glFailInfo - Refering to the note - Don't think we want to distribute sucess/fail info to all GLOs. Just send the success/fail info to the requesting GLO and let the other GLOs use the logs to figure out what happened. 3.1.12 & 3.1.13 glaQueryRequest & glaQueryResponse - The mechansims should be extensible, as there are surely more things the GLO would ask of the GLA than the supportedAlgorithms. Make it an ANY definded by. 3.1.14 glKey - glIdentifier is the shared KEK's key identifier. It should be an OCTET STRING to match the keyIdentifier in RecipientInfo.kekri. - Instead of the term Greenwich Mean Time use UTC. 3.2.2 Combining Request and Response - Though the option to allow individual encryption of messages is allowed, it is a bad practice. Please remove the description of individually encrypting the messages. - The order of processing for glAddMembers and gLRekey should be reversed. Also, not sure why you;d care about processing glSucessInfo before glKey. 4 Administrative Messages - Clearly indicate that the eaxct procedures are not required only that out must be supported. 4.1 Assign KEK to GL - Make sure to add an error for the GLA to tell the GLO that it does not have a certificate. Cheers, spt From owner-ietf-smime Thu Aug 17 09:59:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26198 for ietf-smime-bks; Thu, 17 Aug 2000 09:59:58 -0700 (PDT) Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA26173; Thu, 17 Aug 2000 09:58:55 -0700 (PDT) From: announce@leisurewebcams.com Message-Id: <200008171658.JAA26173@ns.secondary.com> Date: Thu, 17 Aug 2000 14:23:35 Subject: LeisureWebcams.com - See the World Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-ietf-smime Fri Aug 18 06:04:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA00608 for ietf-smime-bks; Fri, 18 Aug 2000 06:04:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00604 for ; Fri, 18 Aug 2000 06:04:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27275; Fri, 18 Aug 2000 09:04:49 -0400 (EDT) Message-Id: <200008181304.JAA27275@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-06.txt Date: Fri, 18 Aug 2000 09:04:49 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-06.txt Pages : Date : 17-Aug-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000817143653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000817143653.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Aug 22 13:56:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13787 for ietf-smime-bks; Tue, 22 Aug 2000 13:56:17 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13783 for ; Tue, 22 Aug 2000 13:56:16 -0700 (PDT) Received: from rhousley_laptop (A32161.resnet.ucsb.edu [128.111.32.161]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA18216; Tue, 22 Aug 2000 13:55:35 -0700 (PDT) Message-Id: <4.2.0.58.20000822141842.00acd640@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Aug 2000 14:23:41 -0400 To: "Jim Schaad" From: Russ Housley Subject: Re: Comments on the RSAES-OAEP draft Cc: "Ietf-Smime" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: >1. Given that the question has been raised on at least one IETF mailing >list, it might be advisable to state that the public key algorithm for rsa >in a certificate is the same for v1.5 and v2.0. Agree. I updated the Introduction to include: CMS supports variety of architectures for certificate-based key management, particularly the one defined by the PKIX working group [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the same RSA public key information. Thus, a certified RSA public key may be used with either RSA key transport technique. >2. You have consistantly gotten the RFC number for the v2.0 draft >incorrect. It is 2437 not 2347. Ooops. I now reference RFC 2437. Russ From owner-ietf-smime Tue Aug 22 15:15:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15090 for ietf-smime-bks; Tue, 22 Aug 2000 15:15:02 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15085 for ; Tue, 22 Aug 2000 15:15:01 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (A32161.resnet.ucsb.edu [128.111.32.161]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id PAA19230; Tue, 22 Aug 2000 15:14:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20000822173131.00c1ded0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 2 (High) Date: Tue, 22 Aug 2000 17:47:16 -0400 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: draft-ietf-smime-idea-06.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Marcus: The draft-ietf-smime-idea-06.txt document has completed S/MIME WG Last Call. It is ready for IESG review and subsequent publication as an Informational RFC. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-06.txt Date : 17-Aug-00 Russ From owner-ietf-smime Thu Aug 24 06:25:37 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA17339 for ietf-smime-bks; Thu, 24 Aug 2000 06:25:37 -0700 (PDT) Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA17332 for ; Thu, 24 Aug 2000 06:25:25 -0700 (PDT) Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.3.2.6) with SMTP id /m1/aimcque/jmail.rcv/0/jmb39a58f30; Thu, 24 Aug 2000 13:22:17 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.3.2.6) with SMTP id /m0/aimcque/jmail.rcv/4/jmb399d5a43; Fri, 18 Aug 2000 14:44:08 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA00526 for ietf-123-outbound.01@ietf.org; Fri, 18 Aug 2000 09:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id JAA00514 for ; Fri, 18 Aug 2000 09:04:50 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27275; Fri, 18 Aug 2000 09:04:49 -0400 (EDT) Message-Id: <200008181304.JAA27275@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-06.txt Date: Fri, 18 Aug 2000 09:04:49 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-06.txt Pages : Date : 17-Aug-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000817143653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000817143653.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Aug 24 14:20:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA05816 for ietf-smime-bks; Thu, 24 Aug 2000 14:20:28 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05812 for ; Thu, 24 Aug 2000 14:20:27 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 17:20:44 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D039D@wfhqex01.wangfed.com> From: "Pawling, John" To: "SMIME WG (E-mail)" Subject: 31 July 2000 S/MIME WG Minutes Date: Thu, 24 Aug 2000 17:20:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message includes the minutes of the IETF S/MIME Working Group meeting held on 31 July 2000 in Pittsburgh, Pennsylvania, U.S.A. Briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/. These minutes include comments from the briefing presenters. Reported by John Pawling. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Introductions - Russ Housley Russ reviewed the agenda as follows. Nobody commented on the agenda. Introductions Russ Housley Working Group Status Russ Housley Interoperability Matrix Jim Schaad CERTDIST Draft Discussion Jim Schaad Symmetric Key Distribution Sean Turner Security Policies and Labels Weston Nicolls Message Compression Ned Freed DOMSEC Draft Discussion Bill Ottaway CMS/ESS Examples Paul Hoffman Crypto Algorithm Documents Russ Housley RSA as a MUST Implement Blake Ramsdell Electronic Signature Formats John Ross Signature Policy Format Denis Pinkas Wrap up Russ Housley +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Working Group Status - Russ Housley Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards: RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999 RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999 RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999 RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999 RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999 RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME, R. Zuccherato, March 2000. [Informational] RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling, July 2000. [Informational] The aforementioned documents must meet the following requirements to advance to Draft Standards: 1) Meet requirements documented in RFC 2026 2) Stable, mature, and useful specification 3) At least two independent and interoperable implementations from different code bases 4) Draft Standards cannot reference Proposed Standard RFCs or Experimental RFCs, so the aforementioned RFCs are blocked until the PKIX Certificate and CRL Profile "Son-of-RFC 2459" Internet-Draft (I-D) (draft-ietf-pkix-new-part1-02.txt) progresses to Draft Standard (last call was estimated to begin by 7 August 2000). Russ stated that Jim Schaad has developed an interoperability matrix for RFCs 2630 through 2634. The interoperability matrix is posted at . The matrix indicates which features have and have not been implemented. So far, Microsoft and Wang Government Services (WGS), A Getronics Company, have provided input to the interoperability matrix. WGS has provided input regarding the capabilities of the S/MIME Freeware Library (SFL) including interoperability testing conducted with Microsoft. Russ noted that Paul Hoffman (IMC) has offered to coordinate interoperability testing and to enhance the "Examples of S/MIME Messages" I-D. He also noted that no other organizations have participated in the interoperability testing. He asked that other organizations that have developed S/MIME v3 capabilities should please participate. There are some S/MIME v3 features for which interoperability testing has not been performed between at least two independent implementations. For example, Russ pointed out that the EncryptedData, AuthenticatedData and DigestedData content types have not been tested between two parties. Russ proposed that RFC 2630 should be changed to state that: - EnvelopedData and SignedData MUST be implemented; and - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented. Russ said that he would submit that proposal to the IETF S/MIME working group (WG) mail list. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Interoperability Matrix - Jim Schaad Jim discussed the interoperability matrix for RFCs 2630 through 2634. He has documented the successful completion of two-way interoperability testing for the following number of clauses in each RFC. He noted that he has not completely updated the results based on all interoperability testing performed: RFC Clauses Tested 2630 45 of 96 2631 0 of 13 2632 16 of 21 2633 17 of 61 2634 0 of 81 Jim asked for others to submit input to him at jimsch@exmsft.com. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CERTDIST Draft Discussion - Jim Schaad Jim discussed the Certificate Distribution Specification I-D , May 2000. Based on discussions on the S/MIME WG mail list, Jim stated that there are three camps of thought regarding publishing certificates with secondary support information such as the SMIMECapabilities attribute: 1) Use attribute certificates (AC) 2) Put user's certificates in the signed object (see certdist-05) 3) Omit user's certificates from the signed object Jim stated that the advantage of the AC strategy is that it matches the X.500 schema. The disadvantage is that ACs are "new" and are not necessarily a good use of ACs. Jim stated that the advantage of the strategy to include user certificates in the signed object is that there is a single location from which to retrieve all of the required information. The disadvantages of this strategy are that duplicate information is stored in the directory and there are potential consistency problems. Jim stated that the advantages of the strategy to omit user certificates in the signed object are less data stored in the directory and a single set of user certificates are used for all purposes. The disadvantages of this strategy are that there are potential consistency problems and multiple elements to be retrieved from the directory. Jim conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options: 1) Continue to try and get consensus 2) Adopt on standards track w/o consensus 3) Adopt on experimental track w/o consensus The majority of the meeting attendees who voted chose option 1. Blake Ramsdell asked if these issues should be discussed on the IETF PKIX WG mail list in addition to the S/MIME WG mail list. Russ stated his belief that the interested parties are subscribed to the S/MIME mail list so it is not necessary to discuss the issues on the PKIX mail list. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Symmetric Key Distribution - Jim Schaad for Sean Turner Jim discussed the S/MIME Symmetric Key Distribution I-D, , July 2000. Jim provided significant comments to the symkeydist-00 I-D that Sean incorporated into the symkeydist-01 I-D. Jim stated that major architecture changes were made to the symmetric key distribution strategy. The Key Management Agent (KMA) and Group Management Agent (GMA) were combined into one component called the Group Lists Agent (GLA). This change removes duplicative KMA checks. The change was made based on the assumption that the KMA and GMA will likely be implemented in the same box. Jim briefed that major protocol changes were made to the symmetric key distribution strategy. Instead of defining a new content type, symkeydist-01 specifies that the exchange of data will use a protocol based on RFC 2797, Certificate Management Messages over CMS (CMC). There were many other changes made to the document as a result of changing the architecture and protocols. Jim briefed the following implementation requirements for the control attributes: Implementation Requirement Control Attribute ================================== MAY glUseKEK MAY glDelete MAY glAddMembers MAY glDeleteMembers MAY glRekey MAY glAddOwners MAY glRemoveOwners MAY glkCompromise SHOULD glkRefresh MAY glSuccessInfo MAY glFailInfo MAY glAQueryRequest MAY glAQueryResponse MUST glKey Jim noted that the protocol exchanges between the user and GLA will be changed to "MUST implement" requirements. He also noted that the protocol exchanges between the KMA and GLA will remain as "MUST implement" requirements. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Mapping Company Classification Policy to the S/MIME Security Label - Weston Nicolls The "Implementing Company Classification Policy with the S/MIME Security Label" I-D, , July 2000, was authored by Weston Nicolls. Weston planned to provide a briefing at the meeting, but could not be present due to airline delays. There was no information presented regarding this topic. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Compression - Ned Freed Ned Freed is proposing a MIME encoding to handle compression. His proposal is to compress the message using this MIME encoding before it is signed or encrypted. Ned Freed could not be present at this meeting, so there was no information presented regarding this topic. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DOMSEC Draft Discussion - Bill Ottaway Bill presented a briefing regarding the "Domain Security Services Using S/MIME" I-D , July 2000. Bill stated that there have been two releases of the DOMSEC I-D since the last S/MIME WG meeting. DOMSEC-05 included clarifications based on input from Luis Barriga and included the object identifier for the signatureType attribute. DOMSEC-06 included corrections and clarifications based on input from Jim Schaad, and included an ASN.1 module added. Bill then discussed some issues with some technical proposals from Jim Schaad. In an e-mail message, Jim Schaad stated: "Section 3.0 bullet 1: This concept bothers me. I think that there may be some programs out there that assume at least one signature in a signed data object except for cases such as degenerate certs only messages." Blake Ramsdell reiterated that some applications interpret a signedData with no signerInfos as being a certs-only message. Bill's position is that CMS (section 5.1) states that there may be zero signerInfos, so compliant implementations should be able to process a signedData with zero signerInfos. He asked if any of the other meeting attendees believed that DOMSEC should be changed to omit the use of signedData objects without any signerInfos. None of the meeting attendees responded. In an e-mail message, Jim Schaad also stated: "Section 4 Paragraph Last-2 - How can I possibly enforce this? For Key Transport the sender is anonymous, for Key Agreement the senders certificate is often not examined. Additionally the domain component could change so that does match -- or it might be my domain component that did the re-enecryption and would therefore match my domain name and not the senders domain name." Bill's position is: "The only extra specification to those specified in CMS is that the naming convention and name mapping convention defined in DOMSEC is used. This is specified to locate public keys. For example, if a domain needs to locate the public key for the domain of the recipient w.ottaway@eris.dera.gov.uk then the public key belonging to domain-confidentiality-authority@eris.dera.gov.uk needs to be located, or if not present the public key of an ascendant of the domain name needs to be located." Bill also stated that the DOMSEC messages are encrypted between the originator's domain and the recipient's domain, not the actual recipient user. He stated that the text is intended to explain how an originator domain agent can look up a recipient's name. He will clarify the text. Bill stated that the he believes that the outstanding issues should be resolved and then the DOMSEC I-D should be submitted for last call. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RSA As a Must Implement - Blake Ramsdell Blake Ramsdell proposed that RFC 2630 be changed to require the RSA public key algorithm as the "MUST implement" key management algorithm since the RSA patent will expire on 20 September 2000. He also raised the question of changing RFC 2630 to require the RSA public key algorithm as the "MUST implement" signature algorithm. John Pawling asked if anybody had applied for any patents related to the RSA public key algorithm. Russ Housley stated that was a possibility, since patent filings are confidential until they are published. He noted as an example that an organization applied for a patent regarding the methods for avoiding the "small- subgroup" attacks on the Diffie-Hellman (D-H) key agreement method. He stated that nobody had made any statements to him regarding any patents related to the RSA public key algorithm. John Linn stated that RSA is not applying for any patents (that he knows of) related to the RSA public key algorithm. Pat Cain stated that he was concerned that this significant change would slow down the process of advancing the S/MIME v3 RFCs from Internet Proposed Standards to Internet Draft Standards. Jim Schaad replied that this change would not slow down the process of implementing the S/MIME v3 standards. Russ Housley stated that the changes probably would reset the clock for advancing the S/MIME v3 RFCs from Internet Proposed Standards to Internet Draft Standards. An attendee pointed out that PKCS #1 is not fully tested. Another attendee stated that the group needs to consider the quality of the cryptographic algorithms in addition to patent concerns. Jim Schaad stated that he believes that DSA should remain a "MUST implement" signature algorithm because the signature value requires less bytes, and because it is widely implemented and required. Russ Housley stated that the RFC 2630 Security Considerations section recommends that the PKCS #1 v2.0 Optimal Asymmetric Encryption Padding (RSA with OAEP) technique should be employed instead of the PKCS#1 v1.5 RSA key management algorithm. Therefore, if Ephemeral-Static Diffie-Hellman is no longer going to be the mandatory-to-implement algorithm, then he recommends the use of RSA with OAEP as its replacement. Jim Schaad asked if separating the algorithms-related text from RFC 2630 would mandate a new six-month waiting period. Russ replied that he did not believe that change alone mandated a new six-month waiting period because it does not impact the RFC 2630 core requirements. Phillip Hallam-Baker stated his belief that the "S/MIME v3" mark on a product means that it is interoperable with all S/MIME implementations, so he supports RSA with OAEP rather than D-H. An attendee asked if RSA with OAEP breaks backward compatibility with S/MIME products that implement PKCS#1 v1.5 RSA. Russ replied that it does break backward compatibility. Blake Ramsdell pointed out that using RSA with OAEP was a better option than using Ephemeral-Static (E-S) D-H because the same RSA certificates can be used with both PKCS#1 v1.5 RSA and RSA with OAEP. Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the "mandatory- to-implement" key management algorithm: 1) PKCS#1 v1.5 RSA 2) RSA with OAEP 3) E-S D-H The majority of the meeting attendees who voted chose option 1, An attendee asked if anybody had submitted any patents regarding RSA with OAEP. Russ replied that the OAEP authors told him that they have not submitted any patents relating to OAEP. Dave Solo asked if the group could discuss separate sign and verify "mandatory-to-implement" signature algorithm requirements. Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding Dave's request. The majority of the meeting attendees who voted indicated that there should not be separate sign and verify "mandatory-to-implement" signature algorithm requirements. Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the "mandatory- to-implement" signature algorithm: 1) PKCS#1 v1.5 RSA 2) DSA 3) Both The majority of the meeting attendees who voted chose "Both". Russ stated that he would submit these proposals to the S/MIME WG mail list. He noted that the earliest that the changes could be made would be September 2000. An attendee asked how many organizations have implemented OAEP. Russ replied that he did not know of any S/MIME implementations that include OAEP. An attendee stated that vendors are required to use NIST-approved algorithms for federal procurement efforts. Russ stated that both X9.42 D-H and X9.44 RSA are NIST-approved. Russ noted that the NIST AES winner is supposed to be announced in September 2000. He suggested that the group should discuss whether AES should be the mandatory-to-implement symmetric encryption algorithm instead of Triple-DES. Dave Solo noted that AES is still theoretical. Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the "mandatory- to-implement" symmetric encryption algorithm: 1) Triple-DES 2) AES The vote was evenly split between the two options. Pat Cain recommended that the S/MIME v3 standards should continue to mandate Triple-DES for the immediate future, but that the group could consider AES later. Phillip Hallam-Baker suggested that the S/MIME v3 standards could mandate both Triple-DES and AES. Carlisle Adams stated his belief that AES must be the "mandatory- to-implement" symmetric encryption algorithm. Pat Cain replied that AES may not be implemented until the end of next year. Jim Schaad noted that RSA with OAEP also delays implementation. A meeting attendee stated that the AES has not been published yet, but Carlisle Adams replied that the five AES candidates are well-known. The implication being that people could begin implementing the five AES candidates now. Russ re-iterated that he would submit these proposals to the S/MIME WG mail list. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Examples of S/MIME Messages - Paul Hoffman Paul Hoffman planned to participate in the meeting, but could not be present because he was required to attend another meeting at the same time as the S/MIME WG meeting. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Electronic Signature Formats - John Ross John briefed regarding the "Electronic Signature Formats for long term electronic signatures" I-D, , July 2000. The esformats-01 I-D is based on the ETSI Electronic Signature Infrastructure Standardisation. John briefed that the esformats-00 I-D was split into two documents. One covers Electronic Signature Formats and is proposed to be an informational RFC. The other covers Signature Policy and is proposed to be an experimental RFC. John briefed that esformats-01 uses the following RFCs: -RFC 2630 Cryptographic Message Syntax (CMS) -RFC 2459 PKIX Certificate and CRL Profile -RFC (to be published) PKIX Timestamping protocol -RFC on "Attribute Certificates". He summarized that the esformats-01 I-D defines a process to provide proof of validity of a signature to be used if repudiation is attempted. John stated that the contents of the esformats-01 I-D is technically equivalent to the ETSI ES 201 733 V.1.1 document. ETSI owns the Copyright (C) on this document. John stated that individual copies of the document can be downloaded from . He noted that these are two new ETSI work items: long term Electronic Signature Formats that do not mandate timestamping and long term Electronic Signature Formats based on XML signatures syntax. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Signature Policy Format - Denis Pinkas Denis briefed regarding the "Electronic Signature Policies" I-D, . Denis briefed that the contents of the I-D is based on the signature policy defined in the ETSI ES 201 733 V.1.1.3(2000-05) document. ETSI owns the Copyright (C) on this document. Denis stated that the I-D defines signature policies for electronic signatures. He defined signature policy as a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. He noted that a given legal/contractual context may recognize a particular signature policy as meeting its requirements. He stated that a signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. He said that the signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. He briefed that to allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. He noted that the current document defines the format of the signature policy using ASN.1 and briefed the proposed syntax. Denis concluded with the statement that work on section 5 of the ID continues to define the Conformance Requirements including: 5.1 Signature Policy definition - Any signature policy issued by a Signature Policy Issuer SHALL include ... 5.2 For signer systems - Signer systems MUST be able to process an electronic signature defined in accordance with [ES-FORMATS] against the signer rules of a signature policy defined in accordance with ... 5.3 For verifier systems - Verifier systems MUST be able to process an electronic signature defined in accordance with [ES-FORMATS] against the verifier rules of a signature policy defined in accordance with ... An attendee asked if there was an issue regarding the occurrence of one or more time stamps associated with the signature. Denis responded that the signature policy may mandate a single or multiple TSAs. For example, separate TSAs may be specified for the sender and recipient. Carlisle Adams asked about the timeframe for ETSI. Denis replied that the ASN.1 for the signature format is stable, but the signature policy ASN.1 syntax is still being actively discussed. He believes that there will be a stable signature policy document by the end of the year. John Ross invited comments to both documents. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Wrap Up - Russ Housley Russ asked if there were any other issues to discuss. The meeting attendees were silent. Meeting adjourned. From owner-ietf-smime Fri Aug 25 08:30:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15204 for ietf-smime-bks; Fri, 25 Aug 2000 08:30:38 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA15190 for ; Fri, 25 Aug 2000 08:30:35 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Fri, 25 Aug 2000 08:30:40 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Aug 2000 08:30:40 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5A77055@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: FW: draft-ietf-smime-idea-03 Date: Fri, 25 Aug 2000 08:30:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 15B84EAA42929-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Note that this problem is still present in the -06 draft (that has completed WG last call), and it will potentially lead to interoperability problems. Fortunately, I don't care since it isn't in the base S/MIME spec and I never plan to use it. Blake -----Original Message----- From: Blake Ramsdell Sent: Thursday, June 15, 2000 2:35 PM To: 'jimsch@nwlink.com'; ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 And just to be clear, this absolutely must be fixed (either the text must be corrected to say that the parameters are encoded as ASN.1 NULL or the examples must be corrected as I have pointed out). The MUSTS in the current draft are contradictory. Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Monday, June 12, 2000 1:22 AM To: ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 This has not been taken care of in the -04 draft. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell Sent: Friday, April 14, 2000 4:04 PM To: 'jimsch@nwlink.com'; ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-03 Agree. I think this should be 300D at the beginning, and trim the last two bytes off of both examples. Blake -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, April 14, 2000 12:35 AM To: ietf-smime@imc.org Subject: draft-ietf-smime-idea-03 The S/MIME Capability sequences appear to be wrong. In section 4 paragraph 2, the text states that the parameters field must be absent, however the encoding sequence given has the parameters encoded as NULL. The same is true in paragraph 3 of the same section. jim http://www.nwlink.com From owner-ietf-smime Sat Aug 26 08:57:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27116 for ietf-smime-bks; Sat, 26 Aug 2000 08:57:36 -0700 (PDT) Received: from smtp5s.retemail.es (smtp5s.iddeo.es [62.81.31.74] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27112 for ; Sat, 26 Aug 2000 08:57:34 -0700 (PDT) From: Successisgreat@aol.com Received: from [152.23.36.38] ([62.81.12.15]) by smtp5s.retemail.es (InterMail v4.01.01.00 201-229-111) with SMTP id <20000826155941.DUDH5778.smtp5s@[62.81.12.15]>; Sat, 26 Aug 2000 17:59:41 +0200 Message-ID: <000056ae172f$00002e79$000072ad@152.23.36.39> To: Subject: Cyber-Biz Secrets Date: Sat, 26 Aug 2000 10:48:06 -0400 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: unsubscribe@netease.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Truth Is Finally Revealed.... How Does The Richest Man In The World Use The Greatest Business Secrets Of All Time To Make Over 32.4 Million Dollars A Day?!! No matter who you are, where you live or what your sex, age or race is by the time you finish reading this special article, you will know: * How to start a proven money making business that requires no inventory, no shipping and no employees within 7 days, guaranteed! * How to get a $300 professionally designed Web Site for FREE! * How to increase your sales by more than 137% in 30 days regardless of your business! * How to get paid for a 1000-hour workweek, without going to work! * How to turn 50 cents into $50, with a simple click of a button! * How to get a $179 business-building CD-ROM for FREE! * If you ever wanted a business where you could hit the ground running.... a business where you could just open a box and start making immediate profits.... a business that's completely set up and ready to pull in maximum sales.... with a product that sells itself... then I've got some great news for you! Act NOW <<<<<< There is A DEADLINE!!! >>>>>> Instant Information Request Directions: **>NOTE: You may also just Click Below to send it through your normal e-mail program. mailto:itsyourchoice@netease.com?subject=send_info_on_infomax825 It's much easier to do it this way, it will fill in the return e-mail and subject for you. 2. You will receive the complete info on the reports via e-mail within 24 hours. P.S. Act NOW!-- Only the first 75 requests will be granted to receive this Special Web Site e-Report for *FREE* titled "The Greatest Business Secrets Of All Time" P.P.S. *FREE Download Bonus e-Manual* "Microsoft, Viagra & Your Business Success" given to the first 35 people to respond within the next 24 hours, Your FREE reports will be fulfilled in the order in which they were received. Privacy Policy: We respect your privacy and your e-mail address/name will be kept strictly private it will never be sold, shared or given away for any reason. Simple Removal Instructions: To Be Removed: mailto:unsubscribe@netease.com?subject=remove825 You will then be deleted from our e-mail database forever. NO FLAMES!! You will not be added to the remove database unless you do this. No Exceptions, anything but "remove" in the subject will generate an automatic response. Thank You!! From owner-ietf-smime Wed Aug 30 01:05:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02320 for ietf-smime-bks; Wed, 30 Aug 2000 01:05:44 -0700 (PDT) Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01619; Wed, 30 Aug 2000 01:00:02 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:31 Message-Id: <248.351783.815864@sendflowersamerica.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-) From owner-ietf-smime Wed Aug 30 03:49:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16041 for ietf-smime-bks; Wed, 30 Aug 2000 03:49:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16036 for ; Wed, 30 Aug 2000 03:49:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23562; Wed, 30 Aug 2000 06:50:23 -0400 (EDT) Message-Id: <200008301050.GAA23562@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-compression-01.txt Date: Wed, 30 Aug 2000 06:50:23 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-01.txt Pages : 3 Date : 29-Aug-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level) these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). This document defines a format for using compressed data as a CMS content type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000829112132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000829112132.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Aug 30 06:09:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA24267 for ietf-smime-bks; Wed, 30 Aug 2000 06:09:54 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24262 for ; Wed, 30 Aug 2000 06:09:53 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA22835; Wed, 30 Aug 2000 06:10:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20000830090620.00c04e90@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Aug 2000 09:08:44 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: WG LAST CALL: draft-ietf-smime-compression-01.txt Cc: jis@mit.edu, MLeech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The compression content type definition, draft-ietf-smime-compression-01.txt, is ready for S/MIME WG Last Call. This document is slated to become an Experimental RFC. Last Call will end on 15 September 2000. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-01.txt Pages : 3 Date : 29-Aug-00 Happy reading, Russ From owner-ietf-smime Wed Aug 30 06:40:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25349 for ietf-smime-bks; Wed, 30 Aug 2000 06:40:19 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25343 for ; Wed, 30 Aug 2000 06:40:17 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id BAA05805; Thu, 31 Aug 2000 01:40:57 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96764285725320>; Thu, 31 Aug 2000 01:40:57 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: housley@spyrus.com Subject: Re: WG LAST CALL: draft-ietf-smime-compression-01.txt Cc: ietf-smime@imc.org Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 31 Aug 2000 01:40:57 (NZST) Message-ID: <96764285725320@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >The compression content type definition, draft-ietf-smime-compression-01.txt, >is ready for S/MIME WG Last Call. This document is slated to become an >Experimental RFC. Last Call will end on 15 September 2000. s/Experimental/Informational/ Peter. From owner-ietf-smime Wed Aug 30 09:57:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14098 for ietf-smime-bks; Wed, 30 Aug 2000 09:57:07 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14085; Wed, 30 Aug 2000 09:57:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <96764285725320@kahu.cs.auckland.ac.nz> References: <96764285725320@kahu.cs.auckland.ac.nz> Date: Wed, 30 Aug 2000 09:58:03 -0700 To: pgut001@cs.aucKland.ac.nz, housley@spyrus.com From: Paul Hoffman / IMC Subject: Re: WG LAST CALL: draft-ietf-smime-compression-01.txt Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:40 AM -0700 8/31/00, Peter Gutmann wrote: > >The compression content type definition, >draft-ietf-smime-compression-01.txt, >>is ready for S/MIME WG Last Call. This document is slated to become an >>Experimental RFC. Last Call will end on 15 September 2000. > >s/Experimental/Informational/ I'm not sure I agree with that. If there is even one implementation of it (probably from you, Peter?), then it's appropriate to be Experimental. If there are two, then it might even go on standards track later. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Aug 30 10:42:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA16191 for ietf-smime-bks; Wed, 30 Aug 2000 10:42:26 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16185; Wed, 30 Aug 2000 10:42:24 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA30825; Thu, 31 Aug 2000 05:43:24 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96765740416582>; Thu, 31 Aug 2000 05:43:24 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: phoffman@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-compression-01.txt Cc: ietf-smime@imc.org Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 31 Aug 2000 05:43:24 (NZST) Message-ID: <96765740416582@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman / IMC writes: >I'm not sure I agree with that. If there is even one implementation of it >(probably from you, Peter?), then it's appropriate to be Experimental. If >there are two, then it might even go on standards track later. At the moment there's only one because of long delays in getting it out as an RFC, however judging by the number of people who have asked me about it there'll be more than one fairly soon after it's finally published. Peter. From owner-ietf-smime Thu Aug 31 13:51:16 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17402 for ietf-smime-bks; Thu, 31 Aug 2000 13:51:16 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17397 for ; Thu, 31 Aug 2000 13:51:15 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA13629; Thu, 31 Aug 2000 13:51:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20000831164052.00bf84d0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Aug 2000 16:49:47 -0400 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: Fixed: draft-ietf-smime-idea-07.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Marcus: The draft-ietf-smime-idea-07.txt was submitted. It should be posted today or tomorrow. The error in the draft has been fixed. So, the working group is finished with the document. It is ready for the IESG and subsequent publication as an Informational RFC. Russ >From: "Teiwes, Stephan (iT_SEC)" >To: "'Russ Housley'" >Cc: "'jimsch@nwlink.com'" , > "'blaker@deming.com'" > >Subject: RE: URGENT: draft-ietf-smime-idea-06 >Date: Wed, 30 Aug 2000 16:56:33 +0200 >X-Mailer: Internet Mail Service (5.5.2448.0) > >Russ, Blake and Jim, > >I'd like to apologize for not having immediately considered your important >comment on our draft. However, I didn't receive the your e-mails from IMC. >The reason is not clear to me as I am on the mailing list. However, a >collegue of mine also reported to me that he didn't receive e-mails from the >SMIME WG for some weeks. Thus, I've to check what's going wrong. > >Your comment is correct! We've changed the encoding sequences and send a >modified draft to the ietf. > >Thanks a lot for your help and your understanding. > >*Stephan > > > >-----Original Message----- >From: Russ Housley [mailto:housley@spyrus.com] >Sent: Montag, 28. August 2000 19:05 >To: stephan.teiwes@it-sec.com; peter.hartmann@it-sec.com; >diego.kuenzi@it-sec.com >Subject: URGENT: draft-ietf-smime-idea-06 > > >Obviously, I missed one of the changes in my summary. How quickly can you >generate one that repairs this problem? > >Russ > > >At 08:30 AM 08/25/2000 -0700, you wrote: > >Note that this problem is still present in the -06 draft (that has >completed > >WG last call), and it will potentially lead to interoperability problems. > >Fortunately, I don't care since it isn't in the base S/MIME spec and I >never > >plan to use it. > > > >Blake > > > >-----Original Message----- > >From: Blake Ramsdell > >Sent: Thursday, June 15, 2000 2:35 PM > >To: 'jimsch@nwlink.com'; ietf-smime@imc.org > >Subject: RE: draft-ietf-smime-idea-03 > > > > > >And just to be clear, this absolutely must be fixed (either the text must >be > >corrected to say that the parameters are encoded as ASN.1 NULL or the > >examples must be corrected as I have pointed out). The MUSTS in the >current > >draft are contradictory. > > > >Blake > > > >-----Original Message----- > >From: Jim Schaad [mailto:jimsch@nwlink.com] > >Sent: Monday, June 12, 2000 1:22 AM > >To: ietf-smime@imc.org > >Subject: RE: draft-ietf-smime-idea-03 > > > > > >This has not been taken care of in the -04 draft. > > > >jim > > > >-----Original Message----- > >From: owner-ietf-smime@mail.imc.org > >[mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Blake Ramsdell > >Sent: Friday, April 14, 2000 4:04 PM > >To: 'jimsch@nwlink.com'; ietf-smime@imc.org > >Subject: RE: draft-ietf-smime-idea-03 > > > > > >Agree. I think this should be 300D at the beginning, and trim the last two > >bytes off of both examples. > > > >Blake > > > >-----Original Message----- > >From: Jim Schaad [mailto:jimsch@nwlink.com] > >Sent: Friday, April 14, 2000 12:35 AM > >To: ietf-smime@imc.org > >Subject: draft-ietf-smime-idea-03 > > > > > >The S/MIME Capability sequences appear to be wrong. In section 4 paragraph > >2, > >the text states that the parameters field must be absent, however the > >encoding > >sequence given has the parameters encoded as NULL. The same is true in > >paragraph > >3 of the same section. > > > >jim > >http://www.nwlink.com From owner-ietf-smime Sat Sep 2 14:01:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08987 for ietf-smime-bks; Sat, 2 Sep 2000 14:01:16 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA08983 for ; Sat, 2 Sep 2000 14:01:15 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Sat, 02 Sep 2000 14:02:00 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Sat, 2 Sep 2000 14:02:00 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5A770E7@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: Mandatory to implement key wrap algorithm for S/MIME summary Date: Sat, 2 Sep 2000 14:01:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 15AFB54280456-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It appears that we have reached at least preliminary consensus for the mandatory to implement algorithms for S/MIME. Note that these mandatory to implement algorithms are not for CMS in general, but for the S/MIME profile of CMS. 1. The mandatory to implement algorithms should change in light of the patent expiration for RSA. 2. The use of RSA as the mandatory to implement key wrapping algorithm is acceptable, and the mode of operation will be PKCS #1 v1.5, not OAEP. This seems to reflect the reasoned discussions of at least ten working group participants. This will include adding a security consideration note that explains the attack and points to a descriptive reference. 3. The use of Diffie-Hellman will only be included for backward compatibility, and thus can be a SHOULD implement. If we are going to use the PKCS #1 v1.5 implementation of RSA key wrapping, then we should document the concerns about its use, and potentially point to an RFC or other document that has a full explanation (as Paul pointed out earlier). Based on this list, I believe that enough information exists to move draft-ramsdell-smime31-msg and draft-ramsdell-smime31-cert into the working group, and start finishing this up. Blake From owner-ietf-smime Sat Sep 2 14:04:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09031 for ietf-smime-bks; Sat, 2 Sep 2000 14:04:31 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09024 for ; Sat, 2 Sep 2000 14:04:29 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Sat, 02 Sep 2000 14:05:17 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Sat, 2 Sep 2000 14:05:16 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C5A770E8@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary Date: Sat, 2 Sep 2000 14:05:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 15AFB40780466-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One more thing -- it may be important to do some kind of revision to the working group charter if we would like to finish this up. Based on the level of interest both on the mailing list and at the meeting in Pittsburgh, it seems like a no-brainer and that people are interested in pursuing this in the working group, and the charter should be amended. Blake > -----Original Message----- > From: Blake Ramsdell > Sent: Saturday, September 02, 2000 2:02 PM > To: 'ietf-smime@imc.org' > Subject: Mandatory to implement key wrap algorithm for S/MIME summary > > It appears that we have reached at least preliminary consensus for the > mandatory to implement algorithms for S/MIME. Note that these mandatory > to implement algorithms are not for CMS in general, but for the S/MIME > profile of CMS. > > 1. The mandatory to implement algorithms should change in light of the > patent expiration for RSA. > > 2. The use of RSA as the mandatory to implement key wrapping algorithm is > acceptable, and the mode of operation will be PKCS #1 v1.5, not OAEP. > This seems to reflect the reasoned discussions of at least ten working > group participants. This will include adding a security consideration > note that explains the attack and points to a descriptive reference. > > 3. The use of Diffie-Hellman will only be included for backward > compatibility, and thus can be a SHOULD implement. > > If we are going to use the PKCS #1 v1.5 implementation of RSA key > wrapping, then we should document the concerns about its use, and > potentially point to an RFC or other document that has a full explanation > (as Paul pointed out earlier). > > Based on this list, I believe that enough information exists to move > draft-ramsdell-smime31-msg and draft-ramsdell-smime31-cert into the > working group, and start finishing this up. > > Blake From owner-ietf-smime Tue Sep 5 03:44:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04126 for ietf-smime-bks; Tue, 5 Sep 2000 03:44:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04122 for ; Tue, 5 Sep 2000 03:44:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27370; Tue, 5 Sep 2000 06:45:54 -0400 (EDT) Message-Id: <200009051045.GAA27370@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-07.txt Date: Tue, 05 Sep 2000 06:45:54 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-07.txt Pages : 6 Date : 01-Sep-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000901143530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000901143530.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Sep 5 09:41:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02051 for ietf-smime-bks; Tue, 5 Sep 2000 09:41:21 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02047 for ; Tue, 5 Sep 2000 09:41:20 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Sep 2000 12:42:45 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D03F8@wfhqex01.wangfed.com> From: "Pawling, John" To: "'ietf-smime@imc.org'" Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary Date: Tue, 5 Sep 2000 12:42:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Blake stated: "Note that these mandatory to implement algorithms are not for CMS in general, but for the S/MIME profile of CMS." I have the following comments: RFC 2630 (CMS), section 12.3.1, states: "CMS implementations must include key agreement using X9.42 Ephemeral-Static Diffie-Hellman." To be consistent with the working group's consensus, I believe that this text needs to be changed to: "CMS implementations should include key agreement using X9.42 Ephemeral-Static Diffie-Hellman." RFC 2630, section 12.3.2, states: "CMS implementations should include key transport using RSA." To be consistent with the working group's consensus, I believe that this text needs to be changed to: "CMS implementations must include key transport using RSA." RFC 2630, section 12.2, states: "CMS implementations must include DSA. CMS implementations may include RSA." To be consistent with the working group's consensus, I believe that this text needs to be changed to: "CMS implementations must include both DSA and RSA." ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-ietf-smime Tue Sep 5 14:17:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA11047 for ietf-smime-bks; Tue, 5 Sep 2000 14:17:13 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11043 for ; Tue, 5 Sep 2000 14:17:12 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA01131 for ; Tue, 5 Sep 2000 17:01:44 -0400 (EDT) Message-Id: <200009052101.RAA01127@roadblock.missi.ncsc.mil> Date: Tue, 5 Sep 2000 17:13:17 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BRIsUomwU8pgvP+CMlvzCw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, I agree with Blake's implication that CMS "should not" (little letters) contain algorithm requirements; conformance should be controlled exclusively by specifications which reference CMS. This enables CMS to remain stable as opinions concerning algorithms change. Where would we be if X.509 said every certificate-using application MUST support id-sa-sqMod-nWithRSA signatures? I believe the statements quoted below should be removed without replacement in the next version of CMS. Dave > From: "Pawling, John" > To: "'ietf-smime@imc.org'" > Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary > Date: Tue, 5 Sep 2000 12:42:19 -0400 > > All, > > Blake stated: "Note that these mandatory to implement algorithms are not for > CMS in general, but for the S/MIME profile of CMS." I have the following > comments: > > RFC 2630 (CMS), section 12.3.1, states: "CMS implementations must include > key agreement using X9.42 Ephemeral-Static Diffie-Hellman." To be > consistent with the working group's consensus, I believe that this text > needs to be changed to: "CMS implementations should include key agreement > using X9.42 Ephemeral-Static Diffie-Hellman." > > RFC 2630, section 12.3.2, states: "CMS implementations should include key > transport using RSA." To be consistent with the working group's consensus, I > believe that this text needs to be changed to: "CMS implementations must > include key transport using RSA." > > RFC 2630, section 12.2, states: "CMS implementations must include DSA. CMS > implementations may include RSA." To be consistent with the working group's > consensus, I believe that this text needs to be changed to: "CMS > implementations must include both DSA and RSA." > > ============================================ > John Pawling, john.pawling@wang.com > Wang Government Services, Inc., > A Getronics Company > ============================================ From owner-ietf-smime Wed Sep 6 03:43:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA21198 for ietf-smime-bks; Wed, 6 Sep 2000 03:43:39 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21193 for ; Wed, 6 Sep 2000 03:43:38 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07021; Wed, 6 Sep 2000 06:45:13 -0400 (EDT) Message-Id: <200009061045.GAA07021@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rcek-00.txt Date: Wed, 06 Sep 2000 06:45:13 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Reuse of CMS Content Encryption Keys Author(s) : S. Farrell, S. Turner Filename : draft-ietf-smime-rcek-00.txt Pages : 7 Date : 05-Sep-00 This note describes a way to include a key identifier in a CMS enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rcek-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rcek-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rcek-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000905150122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rcek-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rcek-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905150122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Sep 6 09:00:01 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA13367 for ietf-smime-bks; Wed, 6 Sep 2000 09:00:01 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13360 for ; Wed, 6 Sep 2000 09:00:00 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 12:02:21 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D040B@wfhqex01.wangfed.com> From: "Pawling, John" To: ietf-smime@imc.org Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary Date: Wed, 6 Sep 2000 12:01:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Since RFC 2630 (CMS) will be used as the standard security protocol for several communication protocols that may have different (and changing) sets of algorithm implementation requirements, I agree with Dave Kemp's recommendation to change the text in RFC 2630 stating the algorithm implementation requirements. I believe that it is appropriate for RFC 2630 (or an appendix to RFC 2630) to define how algorithms are used with the CMS security protocol, but should not specify algorithm implementation requirements. For each communication protocol, a separate profile should be developed specifying the algorithm implementation requirements for using RFC 2630 with that communication protocol. For example, the S/MIME v3 algorithm implementation requirements should be stated in the revised S/MIME v3 Message Specification (as proposed by Blake). Recommend the following changes to RFC 2630: 1) Section 12.1: OLD: "CMS implementations must include SHA-1. CMS implementations should include MD5." NEW: "This section describes how the SHA-1 and MD5 digest algorithms are used with CMS." 2) Section 12.2: OLD: "CMS implementations must include DSA. CMS implementations may include RSA." NEW: "This section describes how the DSA and RSA signature algorithms are used with CMS." 3) Section 12.3.1: OLD: "CMS implementations must include key agreement using X9.42 Ephemeral-Static Diffie-Hellman." NEW: "This section describes how key agreement is implemented in CMS using the X9.42 Ephemeral-Static Diffie-Hellman algorithm." 4) Section 12.3.1: OLD: "CMS implementations must include key agreement of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of Triple-DES content-encryption keys. CMS implementations should include key agreement of RC2 pairwise key-encryption keys and RC2 wrapping of RC2 content-encryption keys. The key wrap algorithm for Triple-DES and RC2 is described in section 12.3.3." NEW: "Section 12.3.3.1 specifies the key wrap algorithm for use with CMS for key agreement of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of Triple-DES content-encryption keys. Section 12.3.3.2 specifies the key wrap algorithm for use with CMS for key agreement of RC2 pairwise key-encryption keys and RC2 wrapping of RC2 content-encryption keys." 5) Section 12.3.2: OLD: "CMS implementations should include key transport using RSA. RSA implementations must include key transport of Triple-DES content-encryption keys. RSA implementations should include key transport of RC2 content-encryption keys." NEW: "This section describes how key transport is implemented in CMS using RSA in conjunction with Triple-DES and RC2 content-encryption keys." 6) Section 12.4: OLD: "CMS implementations must include Triple-DES in CBC mode. CMS implementations should include RC2 in CBC mode." NEW: "This section describes how the Triple-DES (in CBC mode) and RC2 (in CBC mode) content encryption algorithms are used with CMS." 7) Section 12.6: OLD: "CMS implementations must include encryption of a Triple-DES content-encryption key with a Triple-DES key-encryption key using the algorithm specified in Sections 12.6.2 and 12.6.3. CMS implementations should include encryption of a RC2 content-encryption key with a RC2 key-encryption key using the algorithm specified in Sections 12.6.4 and 12.6.5." NEW: "Sections 12.6.2 and 12.6.3 specify the algorithm for use with CMS to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key. Sections 12.6.4 and 12.6.5 specify the algorithm for use with CMS to encrypt a RC2 content-encryption key with a RC2 key-encryption key." 8) Section 12, intro: OLD: "This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included." NEW: "This section describes how selected algorithms are used with CMS." Recommend that the revised S/MIME v3 Message Specification should state the S/MIME working group's consensus regarding each of the aforementioned algorithm implementation requirements. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-ietf-smime Sun Sep 10 22:50:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00513 for ietf-smime-bks; Sun, 10 Sep 2000 22:50:00 -0700 (PDT) Received: from cc.sookmyung.ac.kr (cc.sookmyung.ac.kr [203.252.201.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00506 for ; Sun, 10 Sep 2000 22:49:57 -0700 (PDT) Received: from sookmyung.ac.kr (pc_rhee.sookmyung.ac.kr [203.252.195.65]) by cc.sookmyung.ac.kr (8.9.3/8.9.3) with ESMTP id OAA24015 for ; Mon, 11 Sep 2000 14:50:25 +0900 (KST) Message-ID: <39BC72AC.C25D3B7@sookmyung.ac.kr> Date: Mon, 11 Sep 2000 14:50:36 +0900 From: Gwangsoo Rhee X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-smime@imc.org" Subject: Question on basicConstraints from RFC 2632 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The material below is from RFC 2632. Seems to me that the statements about end-entity certificates in the last two paragraphs conflict with each other. One says that end-entity certificates contain a basicConstraints extension and another says they shouldn't. Maybe I misunderstood those statements. Could anyone please enlighten me on the subject? Many thanks. ++++++++++++++++++++++++++++++++++++++++++++++ 4.4.1 Basic Constraints Certificate Extension The basic constraints extension serves to delimit the role and position of an issuing authority or end-entity certificate plays in a chain of certificates. For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as issuing authority certificates. End-entity certificates contain an extension that constrains the certificate from being an issuing authority certificate. Certificates SHOULD contain a basicConstraints extension in CA certificates, and SHOULD NOT contain that extension in end entity certificates. -- --------------------------------------- Gwangsoo Rhee Sookmyung University, Korea tel: +82-2-710-9429 fax: 710-9296 --------------------------------------- From owner-ietf-smime Mon Sep 11 01:43:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03785 for ietf-smime-bks; Mon, 11 Sep 2000 01:43:56 -0700 (PDT) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA03781 for ; Mon, 11 Sep 2000 01:43:55 -0700 (PDT) Received: from dharter (213-123-77-70.btconnect.com [213.123.77.70]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RQJ8JRX5; Mon, 11 Sep 2000 01:39:15 -0700 From: "Darren Harter" To: "'Gwangsoo Rhee'" , Subject: RE: Question on basicConstraints from RFC 2632 Date: Mon, 11 Sep 2000 09:43:42 +0100 Message-ID: <000601c01bcc$63f87700$0100a8c0@entegrity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <39BC72AC.C25D3B7@sookmyung.ac.kr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gwangsoo Rhee, The last paragraph states that an end-entity certificate SHOULD NOT contain a basic contraints extension, it doesn't say that it MUST NOT contain one. As a consequence, an end-entity certificate MAY contain a basic contraints extension, and it if it does the semantic meaning of that extension is as described in the first paragraph. This is a typical example of the standard providing a discretionary recommendation rather than a mandatory instruction. In this case it is quite right and proper, and aids interoperability. It follows the usual aim of IETF standards in being precise in what you send, but flexible in what you receive. Hope this helps, Darren --------------------------------------------------------------------- Darren Harter B.Sc. (Hons) MBCS CEng European Professional Services Group, Entegrity Solutions Corp. -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Gwangsoo Rhee Sent: 11 September 2000 06:51 To: ietf-smime@imc.org Subject: Question on basicConstraints from RFC 2632 The material below is from RFC 2632. Seems to me that the statements about end-entity certificates in the last two paragraphs conflict with each other. One says that end-entity certificates contain a basicConstraints extension and another says they shouldn't. Maybe I misunderstood those statements. Could anyone please enlighten me on the subject? Many thanks. ++++++++++++++++++++++++++++++++++++++++++++++ 4.4.1 Basic Constraints Certificate Extension The basic constraints extension serves to delimit the role and position of an issuing authority or end-entity certificate plays in a chain of certificates. For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as issuing authority certificates. End-entity certificates contain an extension that constrains the certificate from being an issuing authority certificate. Certificates SHOULD contain a basicConstraints extension in CA certificates, and SHOULD NOT contain that extension in end entity certificates. -- --------------------------------------- Gwangsoo Rhee Sookmyung University, Korea tel: +82-2-710-9429 fax: 710-9296 --------------------------------------- From owner-ietf-smime Mon Sep 11 08:12:58 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA12351 for ietf-smime-bks; Mon, 11 Sep 2000 08:12:58 -0700 (PDT) Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12343 for ; Mon, 11 Sep 2000 08:12:57 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA04364 for ; Mon, 11 Sep 2000 10:59:32 -0400 (EDT) Message-Id: <200009111459.KAA04359@roadblock.missi.ncsc.mil> Date: Mon, 11 Sep 2000 11:09:18 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Question on basicConstraints from RFC 2632 To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: G5soqN9sTU+hHqxr3yUyVA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe a paragraph where one sentence says "does contain" and the following sentence says "SHOULD NOT contain" the same information would be contradictory and confusing. However, a (very) careful reading of RFC 2632's "End-entity certificates contain an extension that constrains the certificate from being an issuing authority certificate." reveals that the extension in question need not be basicConstraints. RFC 2459 (the PKIX profile) says that BasicConstraints MUST appear in CA certs and SHOULD NOT appear in end entity certs. It also says that the Key Usage extension, when used, SHOULD be marked critical. Since nearly every end-entity cert will have a key usage extension anyway and since that extension will preclude the EE cert from being an issuing authority cert (if CA usage bit is not set), including basicConstraints in EE certificates which also contain keyUsage is superfluous. In a typical example of a standard catering to every possible viewpoint, son-of-RFC 2459 now says basicConstraints MAY appear, either critical or non-critical, in end entity certificates. I view this as a step away from clarity; SHOULD NOT provides guidance without prohibiting alternatives. If son-of-RFC 2632 is going to contain MAY/SHOULD/MUST statements concerning certificate extensions, I recommend aligning the CA certificate requirement with PKIX and adding a clarifying sentence at the end of section 4.4.1: Certificates SHOULD contain a basicConstraints extension in CA certificates, and SHOULD NOT contain that extension in end entity certificates. End entity certificates SHOULD contain a key usage extension. Section 4.4.2 could use a complete rewrite - it currently says nothing about including keyUsage in EE certs, and also says nothing about distinguishing between signature and encryption certificates. It delves deep into the details of encrypt/decrypt-only, which seems especially bizarre given the absence of even a cursory discussion of digitalSignature, keyEncipherment, and keyAgreement. I'll provide some suggested text for 4.4.2 later. Dave > From: "Darren Harter" > > Gwangsoo Rhee, > > The last paragraph states that an end-entity certificate SHOULD NOT contain > a basic contraints extension, it doesn't say that it MUST NOT contain one. > As a consequence, an end-entity certificate MAY contain a basic contraints > extension, and it if it does the semantic meaning of that extension is as > described in the first paragraph. > > This is a typical example of the standard providing a discretionary > recommendation rather than a mandatory instruction. In this case it is > quite right and proper, and aids interoperability. It follows the usual aim > of IETF standards in being precise in what you send, but flexible in what > you receive. > > Hope this helps, > > Darren > --------------------------------------------------------------------- > Darren Harter B.Sc. (Hons) MBCS CEng > European Professional Services Group, > Entegrity Solutions Corp. > > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Gwangsoo Rhee > Sent: 11 September 2000 06:51 > To: ietf-smime@imc.org > Subject: Question on basicConstraints from RFC 2632 > > > The material below is from RFC 2632. > Seems to me that the statements about end-entity certificates > in the last two paragraphs conflict with each other. > One says that end-entity certificates contain a basicConstraints > extension > and another says they shouldn't. > Maybe I misunderstood those statements. > Could anyone please enlighten me on the subject? > > Many thanks. > > ++++++++++++++++++++++++++++++++++++++++++++++ > > 4.4.1 Basic Constraints Certificate Extension > > The basic constraints extension serves to delimit the role and > position of an issuing authority or end-entity certificate plays in a > chain of certificates. > > For example, certificates issued to CAs and subordinate CAs contain a > basic constraint extension that identifies them as issuing authority > certificates. End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate. > > Certificates SHOULD contain a basicConstraints extension in CA > certificates, and SHOULD NOT contain that extension in end entity > certificates. > > -- From owner-ietf-smime Tue Sep 12 03:49:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12809 for ietf-smime-bks; Tue, 12 Sep 2000 03:49:07 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12800 for ; Tue, 12 Sep 2000 03:49:05 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28788; Tue, 12 Sep 2000 06:51:10 -0400 (EDT) Message-Id: <200009121051.GAA28788@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-ecc-02.txt Date: Tue, 12 Sep 2000 06:51:10 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of ECC Algorithms in CMS Author(s) : D. Brown, S. Blake-Wilson Filename : draft-ietf-smime-ecc-02.txt Pages : 15 Date : 11-Sep-00 This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the ANSI X9F1 working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-ecc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-ecc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000911143530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-ecc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-ecc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143530.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Sep 14 07:35:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18237 for ietf-smime-bks; Thu, 14 Sep 2000 07:35:09 -0700 (PDT) Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18233 for ; Thu, 14 Sep 2000 07:35:07 -0700 (PDT) From: sdjfsdjkfnu@tpntms.anjes.com.tw Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id OAA22718 for ; Thu, 14 Sep 2000 14:36:53 GMT env-from (sdjfsdjkfnu@tpntms.anjes.com.tw) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9ef158v.in; 14 Sep 2000 15:01:00 +0200 To: Date: Thu, 14 Sep 2000 05:26:27 Message-Id: <548.115940.189181@mail.mindspring.com> Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International From owner-ietf-smime Thu Sep 14 08:09:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA18930 for ietf-smime-bks; Thu, 14 Sep 2000 08:09:24 -0700 (PDT) Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18926 for ; Thu, 14 Sep 2000 08:09:22 -0700 (PDT) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 11:13:16 -0400 Message-ID: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com> From: Robert Zuccherato To: ietf-smime@imc.org Subject: Comments on draft-ietf-smime-rcek-00.txt Date: Thu, 14 Sep 2000 11:05:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E5D.3A7CE7B0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01E5D.3A7CE7B0 Content-Type: text/plain; charset="iso-8859-1" I have a few comments on the draft proposing the re-use of content encryption keys (draft-ietf-smime-rcek-00.txt). The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service attack in two ways. First, the attacker could just resend a message MaxDecrypt times and the CEKReference would no longer be valid and potentially not accessible. Does it make more sense to limit the lifetime of the CEKReference by time (maybe give the number of seconds it is to be active) instead of number of decrypts? Also, since the attribute is unprotected it could be changed (i.e. reduced) so that the CEKReference isn't available as long as intended. Why not allow the attribute to be protected? These possibilities should at least be mentioned in the Security Considerations. Why not just mandate that the CEK and KEK algorithms must be the same? This wouldn't seem to be too much of an imposition. This removes the need for a KDF. If you really want to allow different algorithms, the KDF included seems kind of ad-hoc. I would be more comfortable if a more standard KDF was used. Perhaps the KDF from IEEE P1363 would be appropriate. Thanks, Robert Zuccherato Entrust Technologies ------_=_NextPart_001_01C01E5D.3A7CE7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-smime-rcek-00.txt

I have a few comments on the draft = proposing the re-use of content encryption keys = (draft-ietf-smime-rcek-00.txt). 

The CEKMaxDecrypts makes this scheme = vulnerable to a denial-of-service attack in two ways.  First, the = attacker could just resend a message MaxDecrypt times and the = CEKReference would no longer be valid and potentially not = accessible.  Does it make more sense to limit the lifetime of the = CEKReference by time (maybe give the number of seconds it is to be = active) instead of number of decrypts?  Also, since the attribute = is unprotected it could be changed (i.e. reduced) so that the = CEKReference isn't available as long as intended.  Why not allow = the attribute to be protected?  These possibilities should at = least be mentioned in the Security Considerations.

Why not just mandate that the CEK and = KEK algorithms must be the same?  This wouldn't seem to be too = much of an imposition.  This removes the need for a KDF.  If = you really want to allow different algorithms, the KDF included seems = kind of ad-hoc.  I would be more comfortable if a more standard = KDF was used.  Perhaps the KDF from IEEE P1363 would be = appropriate.

Thanks,

        Robert Zuccherato
        Entrust Technologies

------_=_NextPart_001_01C01E5D.3A7CE7B0-- From owner-ietf-smime Thu Sep 14 11:48:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28552 for ietf-smime-bks; Thu, 14 Sep 2000 11:48:13 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28548 for ; Thu, 14 Sep 2000 11:48:12 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA25686; Thu, 14 Sep 2000 11:49:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20000914144037.00bb1bf0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Sep 2000 14:46:56 -0400 To: Robert Zuccherato From: Russ Housley Subject: Re: Comments on draft-ietf-smime-rcek-00.txt Cc: ietf-smime@imc.org In-Reply-To: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert: There are important environments where the KEK and CEK algorithms are different. Usually, these environment mandate a stronger algorithm for the KEK. This seems like a very reasonable policy, and I think that we should not prohibit it. Russ At 11:05 AM 09/14/2000 -0400, Robert Zuccherato wrote: >Why not just mandate that the CEK and KEK algorithms must be the >same? This wouldn't seem to be too much of an imposition. This removes >the need for a KDF. If you really want to allow different algorithms, the >KDF included seems kind of ad-hoc. I would be more comfortable if a more >standard KDF was used. Perhaps the KDF from IEEE P1363 would be appropriate. From owner-ietf-smime Fri Sep 15 04:05:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08024 for ietf-smime-bks; Fri, 15 Sep 2000 04:05:39 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08020 for ; Fri, 15 Sep 2000 04:05:37 -0700 (PDT) Received: by balinese.baltimore.ie; id MAA16808; Fri, 15 Sep 2000 12:07:58 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma016670; Fri, 15 Sep 00 12:07:13 +0100 Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA18177; Fri, 15 Sep 2000 12:07:12 +0100 Message-ID: <39C20375.961C5C64@baltimore.ie> Date: Fri, 15 Sep 2000 12:09:41 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Zuccherato CC: ietf-smime@imc.org, xme Subject: Re: Comments on draft-ietf-smime-rcek-00.txt References: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, > Robert Zuccherato wrote: > > I have a few comments on the draft proposing the re-use of content encryption keys > (draft-ietf-smime-rcek-00.txt). > > The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service attack in two ways. First, > the attacker could just resend a message MaxDecrypt times and the CEKReference would no longer be > valid and potentially not accessible. Does it make more sense to limit the lifetime of the > CEKReference by time (maybe give the number of seconds it is to be active) instead of number of > decrypts? I don't want to get into into clock synchronisation issues, so an expiry time would be bad. A TTL might be ok, but I'd suspect that its easier for an application using this scheme to guess or know the maxDecrypts value rather than a TTL. > Also, since the attribute is unprotected it could be changed (i.e. reduced) so that the > CEKReference isn't available as long as intended. Why not allow the attribute to be protected? Protection is not disallowed, just out of scope for this draft. > These possibilities should at least be mentioned in the Security Considerations. Fair enough, will add some more text along these lines. > > Why not just mandate that the CEK and KEK algorithms must be the same? This wouldn't seem to be > too much of an imposition. This removes the need for a KDF. Though I agree with you, its clear that others don't (e.g. Russ), so it looks like we have to include some KDF:-( > If you really want to allow > different algorithms, the KDF included seems kind of ad-hoc. I would be more comfortable if a > more standard KDF was used. Perhaps the KDF from IEEE P1363 would be appropriate. I'm perfectly happy to change this to whatever folks prefer. The current one is ad-hoc as you say, its (only?) benefit is that it only needs the content encryption algorithm, but I'm not sure if that's significant. What do others think? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-smime Sun Sep 17 14:07:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17667 for ietf-smime-bks; Sun, 17 Sep 2000 14:07:50 -0700 (PDT) Received: from kydmsrv.koyoinc.co.jp (kydmsrv.koyoinc.co.jp [210.145.15.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17663 for ; Sun, 17 Sep 2000 14:07:49 -0700 (PDT) Received: from auiaui ([209.206.4.83]) by kydmsrv.koyoinc.co.jp (Lotus Domino Release 5.0.2b) with ESMTP id 2000091803042413:10187 ; Mon, 18 Sep 2000 03:04:24 +0900 From: "Darren Harris" Subject: Easy Start #39F9 To: join39w X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sun, 17 Sep 2000 12:43:07 -0500 X-MIMETrack: Itemize by SMTP Server on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 03:04:26 AM, Serialize by Router on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 06:21:03 AM, Serialize complete at 2000/09/18 06:21:03 AM Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA17664 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Accepting credit cards for your business has never been so easy & affordable! Our specialty is establishing your merchant account! NO APPLICATION FEE! NO PROGRAMMING FEE! $9.95 PROCESSING FEE Call today and apply: (888) 264-9272 Now you can design your web site with our complete software package, which includes: Domain Registration Web Hosting Web Design Tools Shopping Cart Credit Card Processing Integration Quick, Easy and Affordable at just $99.00! Call (888) 264-9272 and order today! ************************************************************ If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:ylkp2@netscape.net?subject=remove ************************************************************ From owner-ietf-smime Sun Sep 17 21:07:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25092 for ietf-smime-bks; Sun, 17 Sep 2000 21:07:53 -0700 (PDT) Received: from kydmsrv.koyoinc.co.jp (kydmsrv.koyoinc.co.jp [210.145.15.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25087 for ; Sun, 17 Sep 2000 21:07:51 -0700 (PDT) Received: from auiaui ([209.206.4.83]) by kydmsrv.koyoinc.co.jp (Lotus Domino Release 5.0.2b) with ESMTP id 2000091803042413:10187 ; Mon, 18 Sep 2000 03:04:24 +0900 From: "Darren Harris" Subject: Easy Start #39F9 To: join39w X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sun, 17 Sep 2000 12:43:07 -0500 X-MIMETrack: Itemize by SMTP Server on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 03:04:26 AM, Serialize by Router on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 01:21:56 PM, Serialize complete at 2000/09/18 01:21:56 PM Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA25089 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Accepting credit cards for your business has never been so easy & affordable! Our specialty is establishing your merchant account! NO APPLICATION FEE! NO PROGRAMMING FEE! $9.95 PROCESSING FEE Call today and apply: (888) 264-9272 Now you can design your web site with our complete software package, which includes: Domain Registration Web Hosting Web Design Tools Shopping Cart Credit Card Processing Integration Quick, Easy and Affordable at just $99.00! Call (888) 264-9272 and order today! ************************************************************ If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:ylkp2@netscape.net?subject=remove ************************************************************ From owner-ietf-smime Mon Sep 18 03:30:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06151 for ietf-smime-bks; Mon, 18 Sep 2000 03:30:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06147 for ; Mon, 18 Sep 2000 03:30:33 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01359; Mon, 18 Sep 2000 06:33:08 -0400 (EDT) Message-Id: <200009181033.GAA01359@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ietf-smime@imc.org From: The IESG Subject: Protocol Action: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard Date: Mon, 18 Sep 2000 06:33:08 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Use of the CAST-128 Encryption Algorithm in CMS' as a Proposed Standard. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary This protocol specifies the mechanisms and OIDs necessary to use the CAST-128 [RFC2144] encryption algorithm with the S/MIME Cryptographic Message Syntax [RFC2630]. This cipher supports a variable length key (40 - 128 bits) and is available worldwide without royalties. It is considered by the cryptographic community as a valid and reasonable cipher. Working Group Summary There was WG consensus on promotion to Proposed Standard. Protocol Quality The protocol has been independently reviewed for the IESG by both Marcus Leech and Jeff Schiller. From owner-ietf-smime Tue Sep 19 07:40:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24946 for ietf-smime-bks; Tue, 19 Sep 2000 07:40:48 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24740; Tue, 19 Sep 2000 07:39:57 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA11985; Tue, 19 Sep 2000 15:42:37 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma011799; Tue, 19 Sep 00 15:41:58 +0100 Received: from ocelot.ie.baltimore.com (IDENT:root@ocelot [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA26305; Tue, 19 Sep 2000 15:41:57 +0100 Received: from ocelot.ie.baltimore.com (afarrell@localhost [127.0.0.1]) by ocelot.ie.baltimore.com (8.8.7/8.8.7) with ESMTP id PAA12950; Tue, 19 Sep 2000 15:41:56 +0100 Message-Id: <200009191441.PAA12950@ocelot.ie.baltimore.com> To: ietf-pkix@imc.org Cc: ietf-smime@imc.org Subject: Re: Q: Is possible indefinite form of length encoding in DER? In-Reply-To: Your message of "Tue, 19 Sep 2000 11:39:46 +0900." <39C6D1F2.F08FE367@initech.com> Date: Tue, 19 Sep 2000 15:41:56 +0100 From: Andrew Farrell Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ChungKil Kim wrote: >In some S/MIME messages, there are indefinite form of length encoding. >Is it possible? >In PKCS specs, only use DER? An important thing to remember is that although it's often specified that a signature must be over the DER encoding of an object, it's not necessarily true that what is transmitted has to be that encoding. On the ridiculous end of this rule is a certificate in which everything is indefinite length encoded - perfectly valid AFAIK, as long as you re-encode before verifying. On the more practical end, it is often impossible to know when composing a PKCS#7 SignedData how long the data being signed is. As a result all the layers surrounding the Content (ContentInfo, SignedData, EncapsulatedContentInfo) are encoded indefinite length, and the content itself is encoded as a contructed octet string. The signature is over the contents octets of the DER encoding, and so it is never necessary even to count the length of the assembled octetstring. The individual strings are simply fed to the digests as they appear. Andrew From owner-ietf-smime Tue Sep 19 09:59:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03528 for ietf-smime-bks; Tue, 19 Sep 2000 09:59:09 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03523; Tue, 19 Sep 2000 09:59:07 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2000 17:00:42 UT Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA17603; Tue, 19 Sep 2000 12:59:06 -0400 (EDT) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0) id ; Tue, 19 Sep 2000 10:01:47 -0700 Message-ID: From: "Kingdon, Kevin" To: "'Andrew Farrell'" , ietf-pkix@imc.org Cc: ietf-smime@imc.org Subject: RE: Q: Is possible indefinite form of length encoding in DER? Date: Tue, 19 Sep 2000 10:01:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: See comments below: -----Original Message----- From: Andrew Farrell [mailto:afarrell@baltimore.ie] Sent: Tuesday, September 19, 2000 7:42 AM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org Subject: Re: Q: Is possible indefinite form of length encoding in DER? On the ridiculous end of this rule is a certificate in which everything is indefinite length encoded - perfectly valid AFAIK, as long as you re-encode before verifying. Further complicating matters is the fact that some commercial products incorrectly sign the BER encoding. So to validate a signature against a BER-encoded message, you may have to try validating the with the transmitted encoding and if that fails try re-coding and validating against the DER-encoding of the message. (Note that signing BER is flawed if there is a possibility that an intermediate processor will re-code the BER encoding into a different but equivalent BER encoding. This usually doesn't happen with BER, but it is expected to happen with XML-encoded documents. Thus there is increased emphasis on "canonicalization" procedures for XML digital signatures.) From owner-ietf-smime Wed Sep 20 05:56:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA22966 for ietf-smime-bks; Wed, 20 Sep 2000 05:56:22 -0700 (PDT) Received: from bdcsql1.al-rostamani.co.ae ([194.170.227.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA22959 for ; Wed, 20 Sep 2000 05:55:55 -0700 (PDT) Date: Wed, 20 Sep 2000 05:55:55 -0700 (PDT) From: nile333@kadet.co.uk Message-Id: <200009201255.FAA22959@ns.secondary.com> Received: from SMTP agent by mail gateway Wed, 20 Sep 2000 17:01:36 --400 Received: from firewall-in.al-rostamani.co.ae by bdcsql1.al-rostamani.co.ae with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id TFDHQ4XS; Wed, 20 Sep 2000 16:42:33 +0400 Received: from SMTP agent by mail gateway Wed, 20 Sep 2000 16:47:36 --400 To: nile333@kadet.co.uk Subject: So, How in the heck have you been? Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So, How in the heck have you been? Do you remember holding previous conversations regarding business and money making opportunities? I did not send this to you in error! You Said: If only I could find an easier way to make a higher income! and If I had more money, I could spend more time with my Family, and less time at work and I sure could use more money so I could pay off my bills once and for all! And I would love to get involved in a business in which will generate money while I am not at work (like a Gas Pump)! Dear Friend, There is a possibility that we haven’t met, but you were chosen by someone to receive this E-Mail. Please, please, print this off and read thoroughly. Be sure that you don’t miss any of the points outlined. Then put it down, and then read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you don’t believe this program will work for you, send it to 10-20 of your closest friends (in which you trust deeply), and ask them what they think? This really works! Have faith, don’t miss this opportunity, get involved also, and it will work for you as it does for us!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program recently dedicated an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand only if you get involved! ********** THE ENTIRE PLAN IS HERE BELOW ********** **** Print This Now For Future Reference **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make AT LEAST $50,000 in less than 90 days! If not, forward this to someone who would like to make this kind of money. It works (like designed) but only for those who follow it to the letter! Please read this program THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello, My name is Johnathon Rourke, I’m from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve yearsdown-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year,I incurred many unforeseen financial problems. I owed my family, friends and creditors over$35,000. The economy was taking a toll on my business and I just could not seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing to share the experience I hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion,were not cost effective. They were either toodifficult for me to comprehend or the initial investment was too muchfor me to risk to see if they would work. But as I was saying, in December of 1997 I received this program.I didn’t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legalaspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal ! After determining the program was LEGAL I decided WHY NOT!?!?? Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don’t need any paper for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week,I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL. Well, I had 196 orders for REPORT #2. 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much need new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won’t work if you don’t try it. This program does work, But you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won’t work and you’ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose toparticipate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, cpuld not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn’t working. Finally, I figured it out. It wasn’t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don’t have to tell you what happened to the unemployment rate because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, THE RICH GET RICHER ANDTHE POOR GET POORER. The traditional methods of making money will never allow you to move up or get rich, inflation will see to that You have just received the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few months than you have everimagined.I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copyof this exciting report to everyone you can think of. One of the people you send this to may send out 50,000 and your name will be on everyone of them! REMEMBER though, ------ the MORE YOU SEND OUT, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! BEFORE YOU delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA. HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say BULL, please read this program carefully. This is not a chain letter,but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for bulk email) and have them send 25,000 50,000 emails for you about $49+. (4) Orders will come to you by postal mail simply e-mail them the Report they ordered. Let me ask you isn’t this about as easy as it gets? By the way there are over 50 MILLION e-mail address with millions more joining the internet each year so don’t worry about running out or saturation. People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and order one. Same thing with this letter. I received this letter many times then one day I decided it was time to try it. YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can’t sell them if you don’t order them). For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail each of the four reports.Save them on your computer so you can send them to the 1,000’s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you’ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk email software and email address so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month! Your cost to participate in this is practically nothing ( surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL let’s say that you decide to start small, just to see how it goes, and we’ll assume you and all those involved email out only 2,000 programs each. Let’s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out thousands of thousands of programs instead of 2,000 (Why stop at 2000?) But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2.Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let’s say you decide to start small to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response). Also assume that everyone else in YOUR ORGANIZATION gets only 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1St level your first 10 send you $5........................$50 2nd level 10 members from those 10 ($5 x 100)............$500 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ------------------------------------------------55,5550 $$$$$ AMAZING ISN’T IT Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100’s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get emails about this plan from you or somebody else and many will work this plan the question is Don’t you want your name to be on the emails they will send out? *** DON’T MISS OUT !!!*** ***JUST TRY IT ONCE !!!*** ***SEE WHAT HAPPENS !!!*** ***YOU'LL BE AMAZED !!!*** ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can’t advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1b The Insider’s Guide to Advertising for Free on the Internet ORDER REPORT #1 FROM: NICK NICHOLAS 473 MICHIGAN ST ST.PAUL, MN 55102 NOTE: I and every member below are dedicated at helping you with this program so it will work for you also. TRY US! REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet ORDER REPORT #2 FROM: DIANE COLON 1811 TAMARIND AVE # 206 LOS ANGELES, CA. 90028 REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: MELISSA HOGENMILLER 3709 MONHEIM ROAD CONOVER, WI 54519 REPORT #4 How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet ORDER REPORT #4 FROM: CATHY BARROW 10 SYCAMORE STREET CONWAY, SC 29527 *************TIPS FOR SUCCESS*************** TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letter (with your name on them). --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be patient and persistent with this program- If you follow the instructions exactly results WILL FOLLOW. $$$$ ************ YOUR SUCCESS GUIDELINES *************** Follow these guidelines to guarantee your success: If you don’t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mail until you do. Then a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don’t continue advertising or sending e-mail until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question: ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? 1. If the answer is no, then please look at the following facts about this super simple MLM program: NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! Nothing to learn, No skills needed! (Surely you know how to send email?) 2. No equipment to buy you already have a computer and internet connection so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Email copies of the reports are FREE!) 4. All of your customers pay you in CASH! This program will change your LIFE FOREEVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above __ SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOT: If you need help with starting a business, registering a business name, learning now income tax is handled, etc., contact your local office of the Small Business Administration (A Federal Agency) 1-800-827-5722 for free help and answers to questions. Also the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington DC. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-ietf-smime Fri Sep 22 09:54:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11388 for ietf-smime-bks; Fri, 22 Sep 2000 09:54:42 -0700 (PDT) Received: from smtp.scotland.net (plug.sol.co.uk [194.247.64.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11160; Fri, 22 Sep 2000 09:52:43 -0700 (PDT) Received: from e2h2p31.scotland.net ([148.176.238.32] helo=JOHNVARSYSTEM) by smtp.scotland.net with smtp (Exim 3.14 #10) id 13cW6N-0007Nu-00; Fri, 22 Sep 2000 17:55:07 +0100 From: "John Ross" To: "ietf-pkix@imc. org" , "Ietf distribution list" Subject: ETSI documents for open comment Date: Fri, 22 Sep 2000 17:54:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Three draft standards which relate to IETF work items in PKIX and S/MIME have been posted on the ETSI El Sign Web-site for comments. Comments are requested on these documents by 13th October 2000 to the ETSI El Sign e-mail list EL-SIGN@LIST.ETSI.FR. To register with the EL-SIGN list and download the draft documents see: http://www.etsi.org/sec/el-sign.htm The three documents are: 1. Qualified Certificate Profile: Please put "QC profile" in the front of the Subject field of all submissions to the e-mail list on this topic. 2. Time Stamping Profile: Please put "TS profile" in the front of the Subject field of all submissions to the e-mail list on this topic. 3. Revised Electronic Signature Formats: Please put "ES Formats" in the front of the Subject field of all submissions to the e-mail list on this topic. Regards György Endersz, Telia Research AB. gyorgy.g.endersz@telia.se Denis Pinkas, Bull. pinkas@bull.net Stefan Santesson, AddTrust. stefan@accurata.se John Ross, Security & Standards. ross@secstan.com From owner-ietf-smime Fri Sep 22 17:06:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20172 for ietf-smime-bks; Fri, 22 Sep 2000 17:06:05 -0700 (PDT) Received: from www.com2000.co.kr (com2000.co.kr [203.236.86.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20168 for ; Fri, 22 Sep 2000 17:05:59 -0700 (PDT) Received: from host ([206.133.176.96]) by www.com2000.co.kr (Lotus Domino Release 5.0.2c) with ESMTP id 2000092309050839:2151 ; Sat, 23 Sep 2000 09:05:08 +0900 From: "Brendon Mills" Subject: Do You Invest? # DEF To: stock39d X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Fri, 22 Sep 2000 18:51:58 -0500 X-MIMETrack: Itemize by SMTP Server on millecom/Com2000(Release 5.0.2c|2000. 2. 18.) at 2000-09-23 09:05:10, Serialize by Router on millecom/Com2000(Release 5.0.2c|2000. 2. 18.) at 2000-09-23 09:05:36, Serialize complete at 2000-09-23 09:05:36 Message-ID: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do you invest in the stockmarket? If you invest in technology stocks and are familiar with their trading patterns, then you must have seen where many a company's stocks have gone from near obscurity to double-digit gains in a very short time frame. These tremendous opportunities have inspired us to seek out similar potential "big gainers" while they are still in their "near obscurity" stage prior to making a big move. These are companies with solid business fundamentals, strong management, and huge upside potential because of a solid product or technology. We believe that such an opportunity exists in Indexonly Technologies. This innovative tech company developed the Internet's first Business Search Directory designed for Internet and Wireless use, utilizing its own unique computerized content filtering and sorting methods, and a committed and proactive community-based franchisee sales force. Their community-based sales force assures users receive the most accurate information on business throughout the world, regardless of whether they are sitting at their computer or traveling. Indexonly.com has a well-developed Path to Profitability (P2P), which means that profitability, is months, not years, away. The Indexonly.com Business Search Directory eliminates, for its users, millions of irrelevant "matches" and virtually all connections to dead links and provides a break-through solution to the all too frequently asked question: "If the Internet is so good, then why can't I find what I am looking for?" http://www.Indexonly.com allows users to find all the plumbers in their area, or all the hotels in the destination they wish to visit. They are not restricted to just companies with Websites or companies that advertise. Indexonly.com lists all companies. The attached illustration demonstrates how you can use your wireless devices to access the Indexonly.com Business Search Directory and with only 4 clicks find a hotel in San Francisco. Then with a push of a button on your PDA or mobile phone, you can then directly contact or telephone the hotel and make a reservation. For more information please contact Kirk Hinton Financial at: Email: khfrelations@hotmail.com Toll free: 1-877-899-9950 or Phone:(604) 605-1225 Visit the site at http://www.indexonly.com //////////////////////////////////////////////////////// If you wish to be removed from this list reply to: mailto:bbker4@netscape.net?subject=remove //////////////////////////////////////////////////////// From owner-ietf-smime Tue Sep 26 07:39:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17637 for ietf-smime-bks; Tue, 26 Sep 2000 07:39:14 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17632 for ; Tue, 26 Sep 2000 07:39:12 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id CAA19499 for ; Wed, 27 Sep 2000 02:42:24 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96997934711908>; Wed, 27 Sep 2000 02:42:27 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Re: Question on basicConstraints from RFC 2632 Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Wed, 27 Sep 2000 02:42:27 (NZST) Message-ID: <96997934711908@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gwangsoo Rhee writes: >The material below is from RFC 2632. Seems to me that the statements about >end-entity certificates in the last two paragraphs conflict with each other. >One says that end-entity certificates contain a basicConstraints extension and >another says they shouldn't. Maybe I misunderstood those statements. Could >anyone please enlighten me on the subject? It's a problem with RFC 2459 which is covered, in the X.509 style guide, http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt. Most of the certs I've seen seem to ignore the RFC 2459 text, including a basicConstraints extension in end entity certs, so the problems described in the guide shouldn't occur much. Peter. From owner-ietf-smime Fri Sep 29 08:44:54 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01147 for ietf-smime-bks; Fri, 29 Sep 2000 08:44:54 -0700 (PDT) Received: from aeposmail.aepos.com ([209.112.11.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA01143 for ; Fri, 29 Sep 2000 08:44:52 -0700 (PDT) From: mkicksee@aepos.adga.ca Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256969.005A757B ; Fri, 29 Sep 2000 12:28:03 -0400 X-Lotus-FromDomain: AEPOS To: ietf-smime@imc.org Message-ID: <85256969.005A7423.00@aeposmail.aepos.com> Date: Fri, 29 Sep 2000 11:50:13 -0400 Subject: ESS Questions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have carefully and meticulously read through RFC2634 (Enhanced Security Services for S/MIME), and have questions about various sections of it. Any insight into these issues would be greatly appreciated. 3.4.2 Processing Equivalent Labels Q. If an organization has a security policy that maps another organization's security labels to its own, and also trusts a message sender to specify equivalent security labels, and the two disagree (e.g. A sender applies Acme's "Confidential" label and claims that this is equivalent to Widgets' "Private", but Widgets' security policy states that Acme's "Confidential" is equivalent to Widgets' "Secret"), which label should the receiving agent (or MLA) at Widgets use for access control? Should the more restrictive of the two be applied? 4.1 Mail List Expansion Q. A mail list agent must add its own mlData record to the mlExpansionHistory attribute in the outer signed layer of the message, creating the mlExpansionHistory attribute (and possibly the signed layer that contains it) as needed. It must also check that all the mlExpansionHistory attributes that it can verify are identical. What happens if an MLA can't verify a particular signerInfo because it uses an unknown algorithm? It cannot modify the mlExpansionHistory attribute in the signerInfo, since it A) cannot trust it, and B) cannot generate the new signature for it using the same algorithm. If it only modifies the signerInfos that it can sign, they no longer match, and the next MLA that can verify all the signerInfos will (correctly) reject the message, since the mlExpansionHistory attributes won't match. The only solution would be to drop the signerInfo that the MLA cannot verify, despite the fact that it may be valid. Q. How should a mail list agent process a message if the only signerInfo in the outer layer is signed using an unknown algorithm? Since it cannot verify the signerInfo, it should not process or expand its mlExpansionHistory list. It should not add an additional outer signature layer, since its attributes would not include those of the previous outer layer. Replacing the existing (possibly valid) signerInfo is not a good option either, since previous MLAs may have specified attributes in it (e.g. lists of additional signed receipt recipients). Should the MLA refuse to process the message? 4.2.3.1 Processing for EnvelopedData Q. When re-encrypting a message (or its content-encryption key), why does the MLA list itself as the message originator? This allows anyone with access to the MLA's private key (e.g. the MLA's administrator) to decrypt any message it has ever processed. Also, the original sender can no longer decrypt copies of the message that were routed. If the original encrypted data is instead retained, and the content encryption key (CEK) is extracted (using the MLA's private key) and encrypted once for each recipient, the originator's copy of the CEK could be left unchanged. Once processing is finished, the MLA would no longer have access to the plaintext. If message archiving is required, the MLA could save a copy of the message in an archive, encrypting the CEK for any desired profile, not necessarily its own. If it were not for the need to search for a security label, this approach would avoid the need for the MLA to extract the plaintext of the message at all, and it would only require the (much smaller) CEK briefly. The MLA would not even need to know the algorithm used to encrypt the message, merely its OID and parameters. 4.2.3.2 Processing for SignedData Q. Step 2 of this process has been changed from the Internet draft version (draft-ietf-smime-ess-09.txt). It seems that now if the "outer" signed data layer is absent or does not contain an mlExpansionHistory attribute, the MLA simply adds a new outer signed layer, lists itself in the mlExpansionHistory attribute, and sends the message to the recipients. It would no longer expand any encrypted data for the recipients. If someone sent a message that was encrypted then signed to the MLA, the recipients would not be able to decrypt it. Have I misread this paragraph? 5. Signing Certificate Attribute Q. How does the signingCertificate attribute enhance the security of the message? The signingCertificate attribute is signed. Therefore, before a receiving agent should trust its value, it must verify the signature. To verify the signature, it must locate the signer's certificate and those of all issuers in a chain until it finds a trusted root certificate. As the receiving agent has already located the certificates required to verify the signature, of what use is the signingCertificate attribute? This is a Catch-22 situation, since the required information is only of use when it is unavailable. Using the signingCertificate to identify authorization certificates is no better. If the signature on the attribute is not trusted, then the policy also cannot be trusted and should be ignored. If the signature on the attribute has been verified, and the authorization policy indicates that the signature is not to be trusted under current circumstances, the policy has already been violated. In fact, the signature should not be trusted to identify the policy that indicates that the signature should not be trusted, and again the policy should be ignored. This is also a Catch-22 situation. An attacker attempting one of the attacks mentioned in this section could replace both the signingCertificate attribute and the certificate, signing the attribute with the new certificate. The recipient would have no way of detecting this, and may be lulled into a false sense of security by the presence of the (substituted) signingCertificate attribute. The only use I can see for this attribute would be in a case where the signature is intended to be used for (as an example) data integrity but not non-repudiation (e.g. a server securing data in transit). In this case, an attribute certificate might identify the usage intended, and the signingCertificate attribute could identify the attribute certificate. This could be achieved more simply either by including the signing certificate's intended uses in the certificate itself, or by a statement (or disclaimer) placed in the signed message itself by the sender stating the intended use of the signature (e.g. "I am signing this message for data integrity purposes. I do not warrant that the information it contains is accurate."). 5.4 Signing Certificate Attribute Definition Q. SigningCertificate is a signed attribute. An MLA processing a message is supposed to copy the values of all the signed attributes in the outer signature layer when applying or replacing a signature layer. Shouldn't the signingCertificate attribute be omitted from this? It would refer to the previous MLA's certificate, not the current MLA's. Also, an MLA may require the signingCertificate attribute for its own signature, and (since there can be only one signingCertificate attribute in the signerInfo) would not be able to include its own if it copied the previous MLA's signingCertificate attribute. 5.4.1 Certificate Identification Q. Why must SHA-1 be used for generating the hash value of the certificate? Some agents may only process other algorithms (e.g. MD5). Also, someone may develop other (possibly superior) hash algorithms in the future, which might become the new required standard. Why isn't there a field in the ESSCertID to identify the algorithm used? From owner-ietf-smime Fri Sep 29 11:48:22 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA04746 for ietf-smime-bks; Fri, 29 Sep 2000 11:48:22 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04742 for ; Fri, 29 Sep 2000 11:48:19 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Sep 2000 14:53:34 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1553@wfhqex01.wangfed.com> From: "Pawling, John" To: ietf-smime@imc.org Subject: RE: ESS Questions Date: Fri, 29 Sep 2000 14:51:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please see my comments embedded below. ===================================== John Pawling, john.pawling@wang.com Getronics Government Solutions, LLC ===================================== -----Original Message----- From: mkicksee@aepos.adga.ca [mailto:mkicksee@aepos.adga.ca] Sent: Friday, September 29, 2000 11:50 AM To: ietf-smime@imc.org Subject: ESS Questions I have carefully and meticulously read through RFC2634 (Enhanced Security Services for S/MIME), and have questions about various sections of it. Any insight into these issues would be greatly appreciated. 3.4.2 Processing Equivalent Labels Q. If an organization has a security policy that maps another organization's security labels to its own, and also trusts a message sender to specify equivalent security labels, and the two disagree (e.g. A sender applies Acme's "Confidential" label and claims that this is equivalent to Widgets' "Private", but Widgets' security policy states that Acme's "Confidential" is equivalent to Widgets' "Secret"), which label should the receiving agent (or MLA) at Widgets use for access control? Should the more restrictive of the two be applied? [JSP: Section 3.4.2 states: "A receiving agent SHOULD process the ESSSecurityLabel before processing any EquivalentLabels. If the policy in the ESSSecurityLabel is understood by the receiving agent, it MUST process that label and MUST ignore all EquivalentLabels."] 4.1 Mail List Expansion Q. A mail list agent must add its own mlData record to the mlExpansionHistory attribute in the outer signed layer of the message, creating the mlExpansionHistory attribute (and possibly the signed layer that contains it) as needed. It must also check that all the mlExpansionHistory attributes that it can verify are identical. What happens if an MLA can't verify a particular signerInfo because it uses an unknown algorithm? [JSP: Section 4.1. states: "A recipient MUST verify the signature of the SignerInfo which covers the mlExpansionHistory attribute before processing the mlExpansionHistory, and MUST NOT process the mlExpansionHistory attribute unless the signature over it has been verified."] It cannot modify the mlExpansionHistory attribute in the signerInfo, since it A) cannot trust it, and B) cannot generate the new signature for it using the same algorithm. If it only modifies the signerInfos that it can sign, they no longer match, and the next MLA that can verify all the signerInfos will (correctly) reject the message, since the mlExpansionHistory attributes won't match. The only solution would be to drop the signerInfo that the MLA cannot verify, despite the fact that it may be valid. [JSP: This is subject to debate. I believe that the MLA should add a new signerInfo including its mlExpansionHistory attribute and should preserve the signerInfos that it can't verify. If the MLA omits the signerInfos that it can't verify from the new signedData object, then that could cause mail list expansion loops. For example, if an RSA-only MLA sends a message to a DSA-only MLA which is expanding a mail list that includes the original RSA-only MLA.] Q. How should a mail list agent process a message if the only signerInfo in the outer layer is signed using an unknown algorithm? Since it cannot verify the signerInfo, it should not process or expand its mlExpansionHistory list. It should not add an additional outer signature layer, since its attributes would not include those of the previous outer layer. Replacing the existing (possibly valid) signerInfo is not a good option either, since previous MLAs may have specified attributes in it (e.g. lists of additional signed receipt recipients). Should the MLA refuse to process the message? [JSP: Same answer as above.] 4.2.3.1 Processing for EnvelopedData Q. When re-encrypting a message (or its content-encryption key), why does the MLA list itself as the message originator? [JSP: The MLA includes itself as the originator to support the use of key agreement algorithms (such as static-static Diffie-Hellman or Key Exchange Algorithm (KEA)) that require the originator's public key material to generate the key encryption key.] This allows anyone with access to the MLA's private key (e.g. the MLA's administrator) to decrypt any message it has ever processed. [JSP: The fact that the original sender sent the encrypted message to the MLA allows anyone with access to the MLA's private key to decrypt the message.] Also, the original sender can no longer decrypt copies of the message that were routed. [JSP: IF the original sender is part of the expanded mail list, then she will receive a copy that she can decrypt.] If the original encrypted data is instead retained, and the content encryption key (CEK) is extracted (using the MLA's private key) and encrypted once for each recipient, the originator's copy of the CEK could be left unchanged. [JSP: RFC 2634 already specifies that the original encrypted data must be retained. If the original sender needs to decrypt the message sent by the MLA, then the original sender should be included in the mail list, then she will receive a copy that she can decrypt.] Once processing is finished, the MLA would no longer have access to the plaintext. If message archiving is required, the MLA could save a copy of the message in an archive, encrypting the CEK for any desired profile, not necessarily its own. [JSP: The MLA must be trusted. It has access to the key material required to decrypt every encrypted message that is sent to it.] 4.2.3.2 Processing for SignedData Q. Step 2 of this process has been changed from the Internet draft version (draft-ietf-smime-ess-09.txt). It seems that now if the "outer" signed data layer is absent or does not contain an mlExpansionHistory attribute, the MLA simply adds a new outer signed layer, lists itself in the mlExpansionHistory attribute, and sends the message to the recipients. It would no longer expand any encrypted data for the recipients. If someone sent a message that was encrypted then signed to the MLA, the recipients would not be able to decrypt it. Have I misread this paragraph? [JSP: You have misinterpreted the paragraph.] 5. Signing Certificate Attribute Q. How does the signingCertificate attribute enhance the security of the message? [JSP: It can be used to indicate other certificates such as attribute certificates or public key certificates that include additional information (such as the sender's Clearance attribute) needed to process the message.] An attacker attempting one of the attacks mentioned in this section could replace both the signingCertificate attribute and the certificate, signing the attribute with the new certificate. The recipient would have no way of detecting this, and may be lulled into a false sense of security by the presence of the (substituted) signingCertificate attribute. [JSP: If the signingCertificate signed attribute is modified, then the verification of the signature included in the signerInfo will fail.] 5.4 Signing Certificate Attribute Definition Q. SigningCertificate is a signed attribute. An MLA processing a message is supposed to copy the values of all the signed attributes in the outer signature layer when applying or replacing a signature layer. Shouldn't the signingCertificate attribute be omitted from this? It would refer to the previous MLA's certificate, not the current MLA's. Also, an MLA may require the signingCertificate attribute for its own signature, and (since there can be only one signingCertificate attribute in the signerInfo) would not be able to include its own if it copied the previous MLA's signingCertificate attribute. [JSP: I agree that the MLA should omit or replace the SigningCertificate signed attribute in the signerInfo that it signs.] From owner-ietf-smime Sat Sep 30 04:23:26 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA27989 for ietf-smime-bks; Sat, 30 Sep 2000 04:23:26 -0700 (PDT) Received: from tlc.trustair.com.tw (tlc.trustair.com.tw [210.66.110.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27985 for ; Sat, 30 Sep 2000 04:23:19 -0700 (PDT) Message-Id: <200009301123.EAA27985@ns.secondary.com> Received: from host (sdn-ar-001riprovp305.dialsprint.net [168.191.126.171]) by tlc.trustair.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id T70RL8NH; Sat, 30 Sep 2000 19:18:02 +0800 From: "Harry Owen" Subject: VIP List #538B To: join393k X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sat, 30 Sep 2000 07:12:20 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Professional,

You have been selected as a potential candidate for a free
listing in the 2000 - 2001 Edition of the International Executive
Guild Registry=2E

Please accept our congratulations for this coveted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be published in two
different formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
= and professionalism, each candidate is evaluated in keeping with high
= standards of individual achievement=2E In light of this, the Internationa= l
Executive Guild thinks that you may make an interesting biographical
subject=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best wishes for your continued success=2E
International Executive Guild
Listing Dept=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-ietf-smime Mon Oct 2 16:30:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA28160 for ietf-smime-bks; Mon, 2 Oct 2000 16:30:14 -0700 (PDT) Received: from eps1.eps.telstra.com.au (payment.eps.telstra.com.au [192.148.148.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28155 for ; Mon, 2 Oct 2000 16:30:12 -0700 (PDT) Received: from host (sdn-ar-001riprovP303.dialsprint.net [168.191.126.169]) by eps1.eps.telstra.com.au (8.8.8+Sun/8.8.5) with ESMTP id JAA22950; Tue, 3 Oct 2000 09:20:56 +1000 (EST) Message-Id: <200010022320.JAA22950@eps1.eps.telstra.com.au> From: "Dennis Peters" Subject: Real Estate and Business Owners #6AA3 To: real39d@eps1.eps.telstra.com.au X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Mon, 02 Oct 2000 18:50:51 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

SKY DEVELOPMENT SOLUTIONS

We provide the perfect solutions=2E

 

We have investor's that would= like to Buy Real Estate with creative Financing or No money down in USA or Canada=2E=   Our buyer network is looking for commercial Real Estate from
1 million to 100 million

  • Apartme= nt Complex

  • Office = Building

  • Mobile = Home

  • Park Sh= opping Centers

  • Industr= ial Park

  • Hotel a= nd Motel's

 

MOBILE HOME PARKS

$250,000 and up!=
Refinance
purchase
construction
 
 
Did your banker laugh at you when you = asked for a loan?

With our venture capital lending programs w= e fill needs of borrowers who are unable to find conventional financing=2E&nb= sp; For your business startup or your business expansion we can offer you over= 250 venture capital lenders from $100,000 to $1,000,000 and up=2E  (T= hese programs are only for U=2ES Residents)=2E

 

FREE INFORMATION PACK FOR S= ERIOUS INQUIRIES

Name

Add= ress

C= ity, State, Zip

Phone=

Fax

E-mai= l

           

 


List Removal/OPT-OUT Option
Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-ietf-smime Tue Oct 3 03:45:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11760 for ietf-smime-bks; Tue, 3 Oct 2000 03:45:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11755 for ; Tue, 3 Oct 2000 03:45:56 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05449; Tue, 3 Oct 2000 06:49:48 -0400 (EDT) Message-Id: <200010031049.GAA05449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-seclabel-02.txt Date: Tue, 03 Oct 2000 06:49:48 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Implementing Company Classification Policy with the S/MIME Security Label Author(s) : W. Nicolls Filename : draft-ietf-smime-seclabel-02.txt Pages : 10 Date : 02-Oct-00 This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from 3 companies are used to provide worked examples. Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both. The syntax and processing rules for security labels are described in [ESS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-seclabel-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-seclabel-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-seclabel-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-seclabel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-seclabel-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120637.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Oct 5 12:22:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09141 for ietf-smime-bks; Thu, 5 Oct 2000 12:22:31 -0700 (PDT) Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA09137 for ; Thu, 5 Oct 2000 12:22:29 -0700 (PDT) From: mkicksee@aepos.adga.ca Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525696F.0065CD10 ; Thu, 5 Oct 2000 14:31:56 -0400 X-Lotus-FromDomain: AEPOS To: ietf-smime@imc.org Message-ID: <8525696F.0065CB77.00@aeposmail.aepos.com> Date: Thu, 5 Oct 2000 13:53:33 -0400 Subject: RE: ESS Questions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >4.2.3.2 Processing for SignedData > >Q. Step 2 of this process has been changed from the >Internet draft version (draft-ietf-smime-ess-09.txt). It >seems that now if the "outer" signed data layer is absent >or does not contain an mlExpansionHistory attribute, the >MLA simply adds a new outer signed layer, lists itself in >the mlExpansionHistory attribute, and sends the message to >the recipients. It would no longer expand any encrypted >data for the recipients. If someone sent a message that >was encrypted then signed to the MLA, the recipients would >not be able to decrypt it. Have I misread this paragraph? > >[JSP: You have misinterpreted the paragraph.] Did I also misinterpret the flowchart (quoted below)? 1. Has a valid signature? YES -> 2. NO -> STOP. 2. Does outermost SignedData layer contain mlExpansionHistory? YES -> Check it, then -> 3. NO -> Sign message (including outermost SignedData that doesn't have mlExpansionHistory), deliver it, STOP. It seems clear that the MLA would not expand encrypted data unless the outer signature is either absent or that of an MLA. From owner-ietf-smime Sun Oct 8 18:03:36 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA12743 for ietf-smime-bks; Sun, 8 Oct 2000 18:03:36 -0700 (PDT) Received: from www.sinet.net.cn (szptt103-190.szptt.net.cn [202.103.190.3] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12738 for ; Sun, 8 Oct 2000 18:03:34 -0700 (PDT) From: rsb@docsj.de Received: from pavilion ([204.32.5.98]) by www.sinet.net.cn (8.8.8+Sun/8.8.8) with SMTP id BAA17566; Mon, 9 Oct 2000 01:03:37 GMT Date: Mon, 9 Oct 2000 01:03:37 GMT Message-Id: <200010090103.BAA17566@www.sinet.net.cn> To: rsb@docsj.de Subject: At last, HERBAL V the all natural alternative! Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-smime Sun Oct 8 20:10:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17184 for ietf-smime-bks; Sun, 8 Oct 2000 20:10:59 -0700 (PDT) Received: from mail1.mia.bellsouth.net (mail1.mia.bellsouth.net [205.152.144.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17179 for ; Sun, 8 Oct 2000 20:10:56 -0700 (PDT) From: bubblehead32@hotmail.com Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail1.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id XAA28957; Sun, 8 Oct 2000 23:14:04 -0400 (EDT) Message-Id: <200010090314.XAA28957@mail1.mia.bellsouth.net> To: <> Subject: WOW!!! Highest Payouts Around!!!!!!!! Date: Sun, 08 Oct 2000 22:56:15 -0400 X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove From owner-ietf-smime Wed Oct 11 13:22:20 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05865 for ietf-smime-bks; Wed, 11 Oct 2000 13:22:20 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05860 for ; Wed, 11 Oct 2000 13:22:19 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA11084 for ; Wed, 11 Oct 2000 13:26:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20001011162204.00bad8a0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Oct 2000 16:23:22 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Agenda for San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is time to start putting together the agenda for the S/MIME WG meeting in San Diego. I have requested a two hour slot. Let me know if you would like a portion of that 2 hours. Russ From owner-ietf-smime Wed Oct 11 14:34:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07550 for ietf-smime-bks; Wed, 11 Oct 2000 14:34:18 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07546 for ; Wed, 11 Oct 2000 14:34:17 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 17:41:28 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1654@wfhqex01.wangfed.com> From: "Pawling, John" To: ietf-smime@imc.org Subject: RE: ESS Questions Date: Wed, 11 Oct 2000 17:38:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, It seems that mkicksee has pointed out an error in RFC 2634. It seems that the second sentence should be deleted from Section 4.2.3.2 Processing for SignedData, bullet 2 as follows: 2. If the outermost SignedData layer includes a signed mlExpansionHistory attribute, the MLA checks for an expansion loop as described in the "Detecting Mail List Expansion Loops" section, then go to step 3. If the outermost SignedData layer does not include a signed mlExpansionHistory attribute, the MLA signs the whole message (including this outermost SignedData layer that doesn't have an mlExpansionHistory attribute), and delivers the updated message to mail list members to complete MLA processing. Example 5 in section 4.2.1 indicates that the MLA would continue processing the layers of the received message if the outermost SignedData layer does not include a signed mlExpansionHistory attribute, so that seems to contradict the second sentence of Section 4.2.3.2, bullet 2. As best I can remember, the second sentence of Section 4.2.3.2, bullet 2 was included in RFC 2634 to address the case in which an MLA is processing a message composed of a single signedData layer. However, it seems that section 3.3 addresses this case, so the second sentence of Section 4.2.3.2, bullet 2 is not needed. Unless somebody objects, I recommend that the second sentence should be deleted from Section 4.2.3.2, bullet 2 and that the flow chart should be updated accordingly. =========================================== John Pawling, john.pawling@getronicsgov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: mkicksee@aepos.adga.ca [mailto:mkicksee@aepos.adga.ca] Sent: Thursday, October 05, 2000 1:54 PM To: ietf-smime@imc.org Subject: RE: ESS Questions >4.2.3.2 Processing for SignedData > >Q. Step 2 of this process has been changed from the >Internet draft version (draft-ietf-smime-ess-09.txt). It >seems that now if the "outer" signed data layer is absent >or does not contain an mlExpansionHistory attribute, the >MLA simply adds a new outer signed layer, lists itself in >the mlExpansionHistory attribute, and sends the message to >the recipients. It would no longer expand any encrypted >data for the recipients. If someone sent a message that >was encrypted then signed to the MLA, the recipients would >not be able to decrypt it. Have I misread this paragraph? > >[JSP: You have misinterpreted the paragraph.] Did I also misinterpret the flowchart (quoted below)? 1. Has a valid signature? YES -> 2. NO -> STOP. 2. Does outermost SignedData layer contain mlExpansionHistory? YES -> Check it, then -> 3. NO -> Sign message (including outermost SignedData that doesn't have mlExpansionHistory), deliver it, STOP. It seems clear that the MLA would not expand encrypted data unless the outer signature is either absent or that of an MLA. From owner-ietf-smime Thu Oct 12 10:16:55 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA09569 for ietf-smime-bks; Thu, 12 Oct 2000 10:16:55 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09564; Thu, 12 Oct 2000 10:16:53 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 13:24:06 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B165E@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.8 S/MIME Freeware Library Now Available Date: Thu, 12 Oct 2000 13:20:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Getronics Government Solutions (GGS) (formerly Wang Government Services) has delivered Version 1.8 of the S/MIME Freeware Library (SFL) source code. The SFL source code files are freely available to everyone from the Fortezza Developer's S/MIME Page . The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. When used in conjunction with the Crypto++ v3.2 freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the MS Windows NT/95/98, Linux and Solaris 2.7 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H, 3DES) provided by the Crypto++ v3.2 library; RSA suite of algorithms provided by the RSA BSAFE v4.2 and Crypto++ v3.2 libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v1.8 SFL uses the v1.3 R4 Enhanced SNACC ASN.1 Library to encode/decode objects. The v1.8 SFL release includes: SFL High- level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested); v1.3 R4 Enhanced SNACC ASN.1 Compiler and Library; test utilities; test drivers and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X S/MIME v2 products. Signed messages have been exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 2630, 2631 and 2634. This testing included the RSA, mandatory S/MIME V3 and Fortezza suites of algorithms. We used the SFL to successfully process all of the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We have also performed limited S/MIME v3 testing with Baltimore and Entrust. The following enhancements are included in the v1.8 SFL release (compared with the v1.7 release): 1) Tested using common v1.3 R4 Enhanced SNACC ASN.1 Library, v1.8 CTILs and LIBCERT libraries shared with the v1.4 Access Control Library (ACL) and v1.8 Certificate Management Library (CML). 2) Added OpenSSL-based PKCS #12 create/read capabilities that can be used in conjunction with any of the CTILs. For example, we used this capability to import Microsoft-created PKCS #12 files directly into the Crypto++ CTIL. CTIL logins optionally accept a PCKS #12 file to obtain both the private key and certificate. 3) Enhanced PKCS #11 (v2.1) CTIL tested with the 30 June 2000 production version of the Litronic Maestro v1.0 crypto library. We successfully used the PKCS #11 CTIL and v1.0 Maestro library to sign/verify and encrypt/decrypt S/MIME v3 messages using a Fortezza Card. We performed signed and encrypted interoperability testing between the PKCS #11 and Fortezza CTILs. We also performed signed interoperability testing between the PKCS #11 and Crypto++ CTILs using DSA. 4) Enhanced SFL and LIBCERT, so LIBCERT can be used independently of SFL (i.e. without SFL source code). 5) Corrected bugs in Fortezza and SPEX/ CTILs. 6) Corrected bugs in Enhanced SNACC ASN.1 Library that caused BIT STRINGs and DEFAULT values to be improperly ASN.1 encoded using the Distinguished Encoding Rules 7) Performed regression testing to ensure that aforementioned enhancements did not break existing SFL functionality. We also delivered updated SFL Application Programming Interface (API) and CTIL API documents. We are still in the process of enhancing and testing the SFL. Future releases will include: additional PKCS #11 CTIL testing; additional SPEX/ CTIL testing; finish CertificateBuilder command line utility; enhancing CertificateBuilder to support creation of Attribute Certificates; add MIME support for test drivers; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; support for other crypto APIs (possible); and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.7, we plan to port the SFL to the following operating systems: HP/UX 11, IBM AIX 3.2 (possibly), SCO 5.0 (possibly) and Macintosh (possibly). The following SFL files are available from the Fortezza Developer's S/MIME Page: 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) smimeR1.8.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for SFL Hi-Level library. 3) snacc13r4rn.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for v1.3 R4 Enhanced SNACC ASN.1 Compiler and Library. Source code is compilable for Linux, Solaris 2.7 and MS Windows NT/95/98/2000 that has been enhanced by GGS to implement the Distinguished Encoding Rules. This file includes a sample test project demonstrating the use of the SNACC classes. 4) smCTIR1.8.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11. 5) smLibCR1.8.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for the LIBCERT library that provides ASN.1 and certificate processing services used by the SFL, ACL and CML. 6) smTest1.8.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for test drivers used to test the SFL. This file also includes sample CMS/ESS test data and test X.509 Certificates. This file also includes test utilities to create X.509 Certificates that each include a D-H, DSA or RSA public key. 7) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. GGS is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License" available from the Fortezza Developer's S/MIME Page. On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. For example, the SFL can be used with the freeware Crypto++ library to obtain 3DES, D-H, RSA and DSA. To use the SFL with Crypto++ the vendor must download the Crypto++ freeware library from the Crypto++ Web Page and then compile it with the GGS-developed Crypto++ CTIL source code. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. =========================================== John Pawling, john.pawling@getronicsgov.com Getronics Government Solutions, LLC =========================================== From owner-ietf-smime Fri Oct 13 10:08:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01380 for ietf-smime-bks; Fri, 13 Oct 2000 10:08:09 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01374 for ; Fri, 13 Oct 2000 10:08:08 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA13174 for ; Fri, 13 Oct 2000 10:12:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20001013130114.00ba26b0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Oct 2000 13:02:36 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: FYI: SHA-2, AES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim Polk posted this to the IETF Working Group chairs and the PKIX Working Group. I am forwarding it to this list to make sure everyone got the word. Russ = = = = = = = = = = NIST has just posted a white paper that specifies hashing algorithms (SHA-256, SHA-384, and SHA-512) that are intended to provide security similar to that of the three AES key sizes. Information can be found at . These algorithms "will be proposed in a draft Federal Information Processing Standard (FIPS) in 2001. These algorithms are being made available for information purposes prior to the publication of the draft FIPS. SHA-256 is a 256-bit hash function that is intended to provide 128 bits of security against collision attacks, and SHA-512 is a 512-bit hash function that is intended to provide 256 bits of security. A 384-bit hash may be obtained by truncating the SHA-512 output." The web site has the NIST contact points. One side note about AES: http://csrc.nist.gov/csor/algorithms.htm contains the object identifiers and ASN.1 type definitions for AES parameters for protocols built on ASN.1. The OIDs for the new hash algorithms will follow next week. Thanks, Tim Polk From owner-ietf-smime Sat Oct 14 08:05:06 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29527 for ietf-smime-bks; Sat, 14 Oct 2000 08:05:06 -0700 (PDT) Received: from dns.flour-mills.com.kw ([168.187.154.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29522 for ; Sat, 14 Oct 2000 08:05:03 -0700 (PDT) Message-Id: <200010141505.IAA29522@ns.secondary.com> Received: from host (1Cust254.tnt1.providence.ri.da.uu.net [63.21.181.254]) by dns.flour-mills.com.kw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T36JG0T3; Sat, 14 Oct 2000 18:07:58 +0100 From: "Charlie Wenscot" Subject: Your Status # 376 To: list94f X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sat, 14 Oct 2000 07:04:54 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Professional,

You have been selected as a potential candidate for a free
listing in the 2000 - 2001 Edition of the International Executive
Guild Registry=2E

Please accept our congratulations for this coveted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be published in two
different formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
= and professionalism, each candidate is evaluated in keeping with high
= standards of individual achievement=2E In light of this, the Internationa= l
Executive Guild thinks that you may make an interesting biographical
subject=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best wishes for your continued success=2E
International Executive Guild
Listing Dept=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-ietf-smime Thu Oct 19 08:44:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA02651 for ietf-smime-bks; Thu, 19 Oct 2000 08:44:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02646 for ; Thu, 19 Oct 2000 08:44:48 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA11131; Thu, 19 Oct 2000 08:49:53 -0700 (PDT) Message-Id: <200010191549.IAA11131@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2984 on CAST-128 in CMS Cc: rfc-ed@ISI.EDU, ietf-smime@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 19 Oct 2000 08:49:53 -0700 From: RFC Editor Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2984 Title: Use of the CAST-128 Encryption Algorithm in CMS Author(s): C. Adams Status: Standards Track Date: October 2000 Mailbox: cadams@entrust.com Pages: 6 Characters: 11591 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-cast-128-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2984.txt This document specifies how to incorporate CAST-128 (RFC2144) into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification (RFC2630) for symmetric content and key encryption. This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001019084811.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2984 --OtherAccess Content-Type: Message/External-body; name="rfc2984.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001019084811.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Oct 23 08:36:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14242 for ietf-smime-bks; Mon, 23 Oct 2000 08:36:21 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14234 for ; Mon, 23 Oct 2000 08:36:19 -0700 (PDT) Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA11044 for ; Mon, 23 Oct 2000 08:41:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20001023114022.019aeef0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Oct 2000 11:41:14 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Fwd: RE: Use of the IDEA Encryption Algorithm in CMS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This should have been posted to the S/MIME WG list, not the PKIX WG mail list. Russ >From: "Teiwes, Stephan (iT_SEC)" >To: "'Maxim Masiutin'" , > "Teiwes, Stephan (iT_SEC)" > , > "Hartmann, Peter (iT_SEC)" > , > diego.kuenzi@it-sec.com, ietf-pkix@imc.org >Subject: RE: Use of the IDEA Encryption Algorithm in CMS >Date: Mon, 23 Oct 2000 16:52:21 +0200 >X-Mailer: Internet Mail Service (5.5.2448.0) >List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ >List-ID: >List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > >Dear Mr. Masuitin, > >thanks a lot. We'll consider your comments and try to improve the draft >accordingly. > >*Stephan Teiwes >iT_Security AG >www.it-sec.com > >-----Original Message----- >From: Maxim Masiutin [mailto:max@ritlabs.com] >Sent: Montag, 23. Oktober 2000 16:41 >To: stephan.teiwes@it-sec.com; peter.hartmann@it-sec.com; >diego.kuenzi@it-sec.com; ietf-pkix@imc.org >Subject: Use of the IDEA Encryption Algorithm in CMS > > >Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft! > > >I have a question about following paragraph in >draft-ietf-smime-idea-07.txt: > >----------- >If IV is specified as above, it MUST be used as initial vector. In >this case, the ciphertext MUST NOT include the initial vector. If >IV is not specified, the first 64 bits of the ciphertext MUST be >considered as the initial vector. However, this alternative of not >including the IV SHOULD NOT be applied in CMS or S/MIME. >----------- > > The last sentence: > >"this alternative of not including the IV [into "iv OCTET STRING" of >IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be >applied in CMS or S/MIME. > > >Could you please expand this sentence by adding one of the short >explanations that I've proposed? > >I do also have a question about the following paragraph: > >------------ >The SMIMECapability SEQUENCE representing the IDEA symmetric >encryption algorithm MUST include the IDEA-CBC OID in the capabilityID >field and the parameters field MUST be absent. The SMIMECapability >SEQUENCE for IDEA encryption SHOULD be included in the symmetric >encryption algorithms portion of the SMIMECapabilities list. The >SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as >follows: 300D 060B 2B06 0104 0181 3C07 0101 02. >------------ > > Why don't you give ASN.1 notation of SMIMECapability SEQUENCE > representing IDEA as well as DER-encoded value? Please add ASN.1 > notation to the draft. Also, please clarify the byte order. > > And a test sample of CMS-message with IDEA will help me a lot! > > Thank you in advance. > > > >-- >Maxim Masiutin, >Software Engineer >RIT Research Labs http://www.ritlabs.com/ From owner-ietf-smime Tue Oct 24 03:05:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA21281 for ietf-smime-bks; Tue, 24 Oct 2000 03:05:15 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21274 for ; Tue, 24 Oct 2000 03:05:10 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02049; Tue, 24 Oct 2000 06:10:48 -0400 (EDT) Message-Id: <200010241010.GAA02049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-04.txt Date: Tue, 24 Oct 2000 06:10:47 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-04.txt Pages : 8 Date : 23-Oct-00 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001023112430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001023112430.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Oct 24 17:00:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA18167 for ietf-smime-bks; Tue, 24 Oct 2000 17:00:57 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18163; Tue, 24 Oct 2000 17:00:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200010241010.GAA02049@ietf.org> References: <200010241010.GAA02049@ietf.org> Date: Tue, 24 Oct 2000 17:06:36 -0700 To: ietf-smime@imc.org, ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-smime-examples-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:10 AM -0400 10/24/00, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the S/MIME Mail Security Working Group >of the IETF. > > Title : Examples of S/MIME Messages > Author(s) : P. Hoffman > Filename : draft-ietf-smime-examples-04.txt > Pages : 8 > Date : 23-Oct-00 It's too bad that there is no emoticon for "really embarrassed". I put out this draft with essentially no changes from the -03 because the -03 expired a long time ago and I have completely ignored it. Well, I ignored in between feeling bad about it. But you get the picture. Because I had also lamely filed the comments people had sent me a year ago about -03 into different folders, I am not sure what need to be fixed. I know that much does need to be fixed, but I am not sure what. Please send (or, probably, re-send) all comments to me and the ietf-smime-examples@imc.org list. And I really, really promise to get -05 out before the cutoff for the San Diego IETF. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed Oct 25 00:14:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA24343 for ietf-smime-bks; Wed, 25 Oct 2000 00:14:09 -0700 (PDT) Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24339 for ; Wed, 25 Oct 2000 00:14:06 -0700 (PDT) Received: from nelson (nelson.cost.se [10.0.0.38]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id IAA19578 for ; Wed, 25 Oct 2000 08:16:28 +0100 (MET) Reply-To: From: "Magnus Svensson" To: Subject: Signature processing question Date: Wed, 25 Oct 2000 09:17:35 +0200 Message-ID: <001801c03e53$a6f6be50$2600000a@cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a question regarding interoperability between S/MIME v2 and v3 agents. After carefully reading through RFC2315 and RFC2630 I found a strange difference in the signature generation process for S/MIME v2 & v3. It seems to me that the signature in v2 is generated over the digest algorithm identifier + message digest while in v3 only over the message digest. Below is a reference to the RFCs: S/MIME v2: In PKCS#7 (RFC 2315), page 16, sec9.4 states: "The input to the digest-encryption process--the value supplied to the signer's digest-encryption algorithm--includes the result of the message-digesting process (informally, the "message digest") and the digest algorithm identifier (or object identifier). The result of the digest-encryption process is the encryption with the signer's private key of the BER encoding of a value of type DigestInfo:" S/MIME v3: In CMS (RFC2630), page 12, sec5.5 states: "The input to the signature generation process includes the result of the message digest calculation process and the signer's private key. The details of the signature generation depend on the signature algorithm employed. The object identifier, along with any parameters, that specifies the signature algorithm employed by the signer is carried in the signatureAlgorithm field." Am I missing something or is it true that the signature processing differs? Lets hope I am wrong, otherwise that would mean: - There is no way a v2 MUA can verify the signature generated by a v3 MUA. - In order to be v2 compatible, a v3 MUA must try both signature processing techniques. If the above statements are correct, should not the CMS specification clarify that this is a backwards incompatible change from PKCS#7? Any help to clarify things in this matter is greatly appreciated. Regards, Magnus Svensson From owner-ietf-smime Wed Oct 25 02:11:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26456 for ietf-smime-bks; Wed, 25 Oct 2000 02:11:10 -0700 (PDT) Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26450 for ; Wed, 25 Oct 2000 02:11:07 -0700 (PDT) Received: from watson [129.27.152.142] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A4EB2D301E2; Wed, 25 Oct 2000 11:16:27 +0200 Received: from localhost [127.0.0.1] by watson (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Wed, 25 Oct 2000 11:11:23 +0100 From: "Dieter Bratko" To: , Subject: AW: Signature processing question Date: Wed, 25 Oct 2000 11:11:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <001801c03e53$a6f6be50$2600000a@cost.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, As implementing S/MIMEv2/v3, my interpretation is, that S/MIMEv3 (CMS) now uses PKCS#1 RSA based signature algorithms (making the DigestInfo wrapping itself) for RSA based signature creation. So -- for RSA signatures -- the DigestInfo wrapping still is done and the signature creation process is compatible to S/MIMEv2. S/MIMEv2 (PKCS#7v1.5) uses the RSA encryption method and does the DigestInfo wrapping outside (and therefore may not be used for, e.g., DSA). Hope, this interpretation is right. Regards, Dieter Bratko -----Ursprüngliche Nachricht----- Von: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]Im Auftrag von Magnus Svensson Gesendet: Mittwoch, 25. Oktober 2000 09:18 An: ietf-smime@imc.org Betreff: Signature processing question I have a question regarding interoperability between S/MIME v2 and v3 agents. After carefully reading through RFC2315 and RFC2630 I found a strange difference in the signature generation process for S/MIME v2 & v3. It seems to me that the signature in v2 is generated over the digest algorithm identifier + message digest while in v3 only over the message digest. Below is a reference to the RFCs: S/MIME v2: In PKCS#7 (RFC 2315), page 16, sec9.4 states: "The input to the digest-encryption process--the value supplied to the signer's digest-encryption algorithm--includes the result of the message-digesting process (informally, the "message digest") and the digest algorithm identifier (or object identifier). The result of the digest-encryption process is the encryption with the signer's private key of the BER encoding of a value of type DigestInfo:" S/MIME v3: In CMS (RFC2630), page 12, sec5.5 states: "The input to the signature generation process includes the result of the message digest calculation process and the signer's private key. The details of the signature generation depend on the signature algorithm employed. The object identifier, along with any parameters, that specifies the signature algorithm employed by the signer is carried in the signatureAlgorithm field." Am I missing something or is it true that the signature processing differs? Lets hope I am wrong, otherwise that would mean: - There is no way a v2 MUA can verify the signature generated by a v3 MUA. - In order to be v2 compatible, a v3 MUA must try both signature processing techniques. If the above statements are correct, should not the CMS specification clarify that this is a backwards incompatible change from PKCS#7? Any help to clarify things in this matter is greatly appreciated. Regards, Magnus Svensson From owner-ietf-smime Wed Oct 25 18:48:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA22063 for ietf-smime-bks; Wed, 25 Oct 2000 18:48:15 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22058 for ; Wed, 25 Oct 2000 18:48:13 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA29186 for ; Thu, 26 Oct 2000 14:53:50 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97252523716719>; Thu, 26 Oct 2000 14:53:57 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Re: compressedData Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 26 Oct 2000 14:53:57 (NZDT) Message-ID: <97252523716719@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Forwarded from an external source for discussion in case anyone has any thoughts... At 08:33 AM 10/14/2000 +0000, Peter Gutmann wrote: >>This seems like an interesting suggestion. What do you think? > >>>As a heads up, the French and Norwegian delegates are interested in a >>>change to the SMIME RFC. They have said they will propose separately an >>>extension of the ID for a compressedData S/MIME content type. Extension >>>consists of an additional field to indicate the uncompressed size of the >>>encapsulated content. I don't know how soon this will happen. > >Hmm, I can see some problems with this, it assumes you know in advance how long >the data stream will be which isn't always the case. Adding an INTEGER >OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll >cause problems for any streaming implementations (for example one of the uses I >mentioned a while back was for securing EDI messages which can be ~100MB long, >there's no way to tell in advance just how long they'll be because the systems >processing the data can't afford to spool 100MB of data to disk while they wait >for the end to appear). I don't have a problem with adding something like >this, I just wouldn't want to mandate it. > >(Having said that, an indication of what the decompressed size info would be > useful for would also be interesting, I can't think of much offhand where it'd > be necessary but I haven't really given it too much thought). From owner-ietf-smime Wed Oct 25 19:48:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23454 for ietf-smime-bks; Wed, 25 Oct 2000 19:48:24 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23450 for ; Wed, 25 Oct 2000 19:48:21 -0700 (PDT) Received: from RHOUSLEY-PC.spyrus.com (dial07.spyrus.com [207.212.34.127]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id TAA04060; Wed, 25 Oct 2000 19:53:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20001025221630.0199d700@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Oct 2000 22:17:43 -0400 To: From: Russ Housley Subject: Re: Signature processing question Cc: In-Reply-To: <001801c03e53$a6f6be50$2600000a@cost.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The signature processing is the same. The RSA-specific language was replaced with text that supports any signature algorithm. Russ At 09:17 AM 10/25/2000 +0200, Magnus Svensson wrote: >I have a question regarding interoperability between S/MIME v2 and v3 >agents. After carefully reading through RFC2315 and RFC2630 I found a >strange difference in the signature generation process for S/MIME v2 & v3. >It seems to me that the signature in v2 is generated over the digest >algorithm identifier + message digest while in v3 only over the message >digest. Below is a reference to the RFCs: > >S/MIME v2: >In PKCS#7 (RFC 2315), page 16, sec9.4 states: >"The input to the digest-encryption process--the value supplied to the >signer's digest-encryption algorithm--includes the result of the >message-digesting process (informally, the "message digest") and the digest >algorithm identifier (or object identifier). The result of the >digest-encryption process is the encryption with the signer's private key of >the BER encoding of a value of type DigestInfo:" > >S/MIME v3: >In CMS (RFC2630), page 12, sec5.5 states: >"The input to the signature generation process includes the result of the >message digest calculation process and the signer's private key. >The details of the signature generation depend on the signature algorithm >employed. The object identifier, along with any >parameters, that specifies the signature algorithm employed by the signer is >carried in the signatureAlgorithm field." > >Am I missing something or is it true that the signature processing differs? >Lets hope I am wrong, otherwise that would mean: >- There is no way a v2 MUA can verify the signature generated by a v3 MUA. >- In order to be v2 compatible, a v3 MUA must try both signature processing >techniques. > >If the above statements are correct, should not the CMS specification >clarify that this is a backwards incompatible change from PKCS#7? >Any help to clarify things in this matter is greatly appreciated. > >Regards, >Magnus Svensson From owner-ietf-smime Thu Oct 26 07:03:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20650 for ietf-smime-bks; Thu, 26 Oct 2000 07:03:56 -0700 (PDT) Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20646 for ; Thu, 26 Oct 2000 07:03:54 -0700 (PDT) From: mkicksee@aepos.adga.ca Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256984.004E0B9F ; Thu, 26 Oct 2000 10:12:27 -0400 X-Lotus-FromDomain: AEPOS To: ietf-smime@imc.org Message-ID: <85256984.004E0B14.00@aeposmail.aepos.com> Date: Thu, 26 Oct 2000 10:12:39 -0400 Subject: re: Compressed Data Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: pgut001@cs.aucKland.ac.nz wrote: >Forwarded from an external source for discussion in case anyone has any thoughts... >>>>As a heads up, the French and Norwegian delegates are interested in a >>>>change to the SMIME RFC. They have said they will propose separately an >>>>extension of the ID for a compressedData S/MIME content type. Extension >>>>consists of an additional field to indicate the uncompressed size of the >>>>encapsulated content. I don't know how soon this will happen. >> >>Hmm, I can see some problems with this, it assumes you know in advance how long >>the data stream will be which isn't always the case. Adding an INTEGER >>OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll >>cause problems for any streaming implementations (for example one of the uses I >>mentioned a while back was for securing EDI messages which can be ~100MB long, >>there's no way to tell in advance just how long they'll be because the systems >>processing the data can't afford to spool 100MB of data to disk while they wait >>for the end to appear). I don't have a problem with adding something like >>this, I just wouldn't want to mandate it. Couldn't the data be broken into smaller chunks (e.g. spooling 1 MB instead of 100MB at a time), and the uncompressed (and also compressed) size of each chunk be indicated? The recipient could then add the uncompressed sizes of all the chunks to get the size of the original (uncompressed) data. Of course, they would need a way to find all the size specifiers relatively quickly, and a count of all the chunks would be nice too... Networking protocols like TCP/IP and IPX/SPX typically break large blocks of data up into manageable chunks, which they call "packets", but they also often have to deal with packets arriving (or not arriving) in arbitrary sequence, which (thank goodness) is not an issue in this case. One thing I'm wondering is how the data compression algorithm will be specified. I assume that new OIDs will have to be defined for each, if such don't already exist. I am also wondering if there would be a way to generate clear-signed compressed content; that is, if a way could be found to incorporate the compressed data into a MIME entity which is then signed as part of a multipart/signed message, and which could be read (and decompressed) by MIME parsers without S/MIME capability. A simple mechanism would be to put the data into a .zip or .tar file attachment and specify that its content disposition is "inline", but I'm sure better ways are possible. From owner-ietf-smime Thu Oct 26 14:44:26 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA02543 for ietf-smime-bks; Thu, 26 Oct 2000 14:44:26 -0700 (PDT) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02539 for ; Thu, 26 Oct 2000 14:44:24 -0700 (PDT) Received: from ieca.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust7.tnt16.rtm1.nl.uu.net [213.116.126.7]) id QQjmpz22454; Thu, 26 Oct 2000 21:49:48 GMT Message-ID: <39F8A6ED.6256B85E@ieca.com> Date: Thu, 26 Oct 2000 23:49:33 +0200 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mkicksee@aepos.adga.ca CC: ietf-smime@imc.org Subject: Re: Compressed Data References: <85256984.004E0B14.00@aeposmail.aepos.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8A330C1AFB332164193A0EDC" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms8A330C1AFB332164193A0EDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I should think that in many cases this value could be read from the operating system, or otherwise known. Since the size determination would be on the send side, you're not generally counting data streaming in by the packet. Of course, somebody will have an exception, but as long as it's optional it seems like a good idea. Chris B. _________________________ mkicksee@aepos.adga.ca wrote: > pgut001@cs.aucKland.ac.nz wrote: > > >Forwarded from an external source for discussion in case anyone has any > thoughts... > > >>>>As a heads up, the French and Norwegian delegates are interested in a > >>>>change to the SMIME RFC. They have said they will propose separately an > >>>>extension of the ID for a compressedData S/MIME content type. Extension > >>>>consists of an additional field to indicate the uncompressed size of the > >>>>encapsulated content. I don't know how soon this will happen. > >> > >>Hmm, I can see some problems with this, it assumes you know in advance how > long > >>the data stream will be which isn't always the case. Adding an INTEGER > >>OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll > >>cause problems for any streaming implementations (for example one of the uses > I > >>mentioned a while back was for securing EDI messages which can be ~100MB long, > >>there's no way to tell in advance just how long they'll be because the systems > >>processing the data can't afford to spool 100MB of data to disk while they > wait > >>for the end to appear). I don't have a problem with adding something like > >>this, I just wouldn't want to mandate it. > > Couldn't the data be broken into smaller chunks (e.g. spooling 1 MB instead > of 100MB at a time), and the uncompressed (and also compressed) size of each > chunk be indicated? The recipient could then add the uncompressed sizes of all > the chunks to get the size of the original (uncompressed) data. Of course, they > would need a way to find all the size specifiers relatively quickly, and a count > of all the chunks would be nice too... > > Networking protocols like TCP/IP and IPX/SPX typically break large blocks of > data up into manageable chunks, which they call "packets", but they also often > have to deal with packets arriving (or not arriving) in arbitrary sequence, > which (thank goodness) is not an issue in this case. > > One thing I'm wondering is how the data compression algorithm will be > specified. I assume that new OIDs will have to be defined for each, if such > don't already exist. > > I am also wondering if there would be a way to generate clear-signed > compressed content; that is, if a way could be found to incorporate the > compressed data into a MIME entity which is then signed as part of a > multipart/signed message, and which could be read (and decompressed) by MIME > parsers without S/MIME capability. A simple mechanism would be to put the data > into a .zip or .tar file attachment and specify that its content disposition is > "inline", but I'm sure better ways are possible. --------------ms8A330C1AFB332164193A0EDC Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ7AYJKoZIhvcNAQcCoIIJ3TCCCdkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B+4wggS4MIIEIaADAgECAhACOZkTH5mWlYOiMWNS0NA/MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTIzMTAwMDAw MFoXDTAwMTIzMDIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxHDAaBgNVBAMUE0NocmlzdG9waGVyIEJvbmF0dGkxIDAe BgkqhkiG9w0BCQEWEWJvbmF0dGljQGllY2EuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB ANKXlrz4lCtsKxQPevEUJ59yPcZpDmBoZnivM/oJtD1bUq0uUPml8eaZThkLVb3lx5Y3bHMe iZUT86EDSuHBp78CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYL YIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCG SAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2 M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVh YzkzYmNhZmY4YTBiYWU2ZGY1ZDcxMTQ5OWJhMmI4NDRmOWYzZWE0NTA2MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEE BQADgYEAPEGSRUMcSfb9eE0h/Bqqe0Q6h0YgoqFEL7MCsCFC3QOwvgNROksoF2+dJOCnOGum vE3Pg6pyXJC02Qmt0qm2hmg3FLTNy0No9UnVld1NH0oejco+eeSfPO2xY0OFj1GojzeGZGfH hmhB1V43k1Be90B9i/Vn4Tw6UsnhIjg9NgMwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVd r+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1Yt xwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEG MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq hkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5 SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVga STyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAcYwggHCAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhACOZkTH5mWlYOiMWNS 0NA/MAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wMDEwMjYyMTQ5MzNaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ KoZIhvcNAQkEMRYEFAJ+UnetVuhIuNSkiQ9oe0jWidkAMA0GCSqGSIb3DQEBAQUABEBNY8CE 4LSkcKmpJ1DLP8yxj/70OLVed7TyphC9mBSeaDz3yw0VqtcApKcd0+iXL0RuJAHHR0Xa36wA ZIaW2+Hn --------------ms8A330C1AFB332164193A0EDC-- From owner-ietf-smime Fri Oct 27 03:32:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20691 for ietf-smime-bks; Fri, 27 Oct 2000 03:32:44 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20687 for ; Fri, 27 Oct 2000 03:32:41 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05538; Fri, 27 Oct 2000 06:38:34 -0400 (EDT) Message-Id: <200010271038.GAA05538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-password-03.txt Date: Fri, 27 Oct 2000 06:38:34 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Password-based Encryption for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-password-03.txt Pages : 11 Date : 26-Oct-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for password-based data encryption. This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which isn't necessarily an algorithm-specific fixed-format key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-password-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-password-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-password-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001026125015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-password-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-password-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001026125015.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Fri Oct 27 03:32:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20683 for ietf-smime-bks; Fri, 27 Oct 2000 03:32:39 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20679 for ; Fri, 27 Oct 2000 03:32:37 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05510; Fri, 27 Oct 2000 06:38:30 -0400 (EDT) Message-Id: <200010271038.GAA05510@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-compression-02.txt Date: Fri, 27 Oct 2000 06:38:29 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-02.txt Pages : 4 Date : 26-Oct-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level) these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). This document defines a format for using compressed data as a CMS content type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001026124955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001026124955.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Oct 30 02:54:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17585 for ietf-smime-bks; Mon, 30 Oct 2000 02:54:31 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17182; Mon, 30 Oct 2000 02:49:54 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA16164; Mon, 30 Oct 2000 12:01:15 +0100 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA17102; Mon, 30 Oct 2000 11:55:00 +0100 Message-ID: <39FD5384.8C34F3A0@bull.net> Date: Mon, 30 Oct 2000 11:55:00 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: Call for papers: INFOSEC 2001 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA17186 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: INFOSEC 2001 15th exhibition and conference on the security of information systems and communications 29.30.31 May - CNIT Paris-La Défense - FRANCE CALL FOR PAPERS Topics may be addressed from a technical, juridical or organizational perspective. For 2001, the Programmes Committee will essentially, though not exclusively, emphasise the following themes: E-business, e-commerce - Insurance coverage for information systems - Personal data: risks, means of protection - Competitive Intelligence (CI) and counter-CI - Crisis management - Law : digital signature - Employees control - Digital evidence and computer forensic - Specific product security (NT, Linux, Oracle, etc.) - etc. PROGRAMMES COMMITTEE President: Pascal LOINTIER, ACE Insurance Members: Prof. Danilo BRUSCHI, Université de Milan, Italie - Michèle COPITET, EGONA CONSULTING - Michel DUPUY, SGDN/DCSSI - Cert A - Paul GRASSART, CLUSIF - Frédéric HUYNH, ARTHUR ANDERSEN - Jean-Philippe JOUAS, 2SI - Me Bruno P. LANGLOIS, ALAIN BENSOUSSAN - AVOCATS - Patrick LAUTIER, CLUSIF - Robert LONGEON, CNRS - Pierre-Marie LORANG, THOMSON CSF-DETEXIS - Marie-Christine MARTEL, SGDN/DCSSI - Denis PINKAS, BULL - Paul RICHY, FRANCE TELECOM - BR/DACR - Philippe ROSE, LE MONDE - INFORMATIQUE - Stéphane ROUHIER, CIGREF - Serge SAGHROUNE, ACCOR - Paul TRESCASES, GIE Cartes Bancaires - Marcel VIGOUROUX, OCLCTIC Organisation: Maryse DELERIS, M.C.I. Sponsorship of CLUSIF (infosec@clusif.asso.fr) Club de la Sécurité des Systèmes d'Information Français and SGDN Premier Ministre - Direction Centrale de la Sécurité des Systèmes d'Information (DCSSI). DEADLINE TO SUBMIT A PROPOSAL : 31.12.2000 PRACTICAL INFORMATION Authors have to send their proposal to M.C.I. (letter, fax or e-mail: congres@mci-salons.fr) by December 31st, 2000: an abstract (maximum of 3 pages) indicating: TITLE of the subject - and complete address of author(s) At the end of January 2001, authors will receive the Programmes Committee's decision. Selected authors will have to send the paper (following detailed instructions) by February 25th, 2001 to be reviewed and definitively accepted. Authors will have to certify their paper will not be published prior to May 31st, 2001. Overtly " commercial " presentations are inappropriate. Free admission offered for speakers (congress and exhibition). INFORMATION & ORGANISATION M.C.I. - Manifestations & Communications Internationales 19 Rue d'Athènes - 75009 PARIS - FRANCE Tél. : (33) 01.44.53.72.20 - Fax : (33) 01.44.53.72.22 E-mail : congres@mci-salons.fr - Web : http://www.mci-salons.fr/infosec From owner-ietf-smime Mon Oct 30 06:30:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA04363 for ietf-smime-bks; Mon, 30 Oct 2000 06:30:16 -0800 (PST) Received: from mail.dexia.be (mail.dexia.be [193.91.97.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04357 for ; Mon, 30 Oct 2000 06:30:13 -0800 (PST) Message-Id: <200010301430.GAA04357@ns.secondary.com> Date: 30 Oct 2000 15:28:09 +0100 From: Laurent Deffranne To: ietf-smime Subject: A general question about S/MIMEv2 & v3 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello all, Could someone give me a brief description of the new fonctionnalities that were implemented in SMIME v3 ? What are the main new capatibilities ? Is this version already implemented in commercial products ? Thanks a lot to all people who could answer me, Regards, L. Deffranne Dexia Bank Belgium From owner-ietf-smime Mon Oct 30 08:07:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10236 for ietf-smime-bks; Mon, 30 Oct 2000 08:07:36 -0800 (PST) Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10231 for ; Mon, 30 Oct 2000 08:07:34 -0800 (PST) Received: from D00425 ([206.222.76.33]) by luc.ab.org (Netscape Messaging Server 3.6) with SMTP id AAAD748; Mon, 30 Oct 2000 11:18:26 -0500 From: "Ozan Gonenc" To: "Laurent Deffranne" , "ietf-smime" Subject: RE: A general question about S/MIMEv2 & v3 Date: Mon, 30 Oct 2000 11:12:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200010301430.GAA04357@ns.secondary.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Laurent, New functionalities include: - Increased interoperability and support for digital signatures (V3 clients support both DSA and RSA) - V3 supports both D-H and RSA - V3 supports secondary crypto algorithms - D-H support is mandatory - ESS (signed receipts, security labels, Secure MLAs, Signed certificates) - V3 agent may generate separate D-H and DSS public/private key pairs on behalf of the user A number of software vendors are beginning to migrate to S/MIME v3 in phases as the demand for extended security services increases. Currently no software vendors have incorporated "full" v3 compliance. Hope this helps! Cheers, ______________________________ Ozan Gonenc, B.Sc. IT Security Consultant AEPOS Technologies Corporation (819) 772-8522 x. 230 (Office) (819) 772-0449 (Fax) -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Laurent Deffranne Sent: October 30, 2000 09:28 To: ietf-smime Subject: A general question about S/MIMEv2 & v3 Hello all, Could someone give me a brief description of the new fonctionnalities that were implemented in SMIME v3 ? What are the main new capatibilities ? Is this version already implemented in commercial products ? Thanks a lot to all people who could answer me, Regards, L. Deffranne Dexia Bank Belgium From owner-ietf-smime Thu Nov 2 03:29:46 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03226 for ietf-smime-bks; Thu, 2 Nov 2000 03:29:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03221 for ; Thu, 2 Nov 2000 03:29:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16351; Thu, 2 Nov 2000 06:36:08 -0500 (EST) Message-Id: <200011021136.GAA16351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-02.txt Date: Thu, 02 Nov 2000 06:36:07 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-02.txt Pages : 62 Date : 01-Nov-00 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Nov 2 11:49:48 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA08077 for ietf-smime-bks; Thu, 2 Nov 2000 11:49:48 -0800 (PST) Received: from nl-imail01.cmg.nl (nl-mail-dmz.cmg-gecis.nl [195.109.155.100]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA08073 for ; Thu, 2 Nov 2000 11:49:46 -0800 (PST) From: Internet-Drafts@ietf.org Received: FROM nl-iscan.cmg.nl BY nl-imail01.cmg.nl ; Thu Nov 02 20:46:17 2000 +0100 Received: FROM nl-amv-route01.cmg.nl BY nl-iscan.cmg.nl ; Thu Nov 02 20:38:28 2000 +0100 Received: from nl-irelay.cmg.nl (NL-IRELAY [10.16.67.60]) by nl-amv-route01.cmg.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WD5NS413; Thu, 2 Nov 2000 20:37:18 +0100 Received: from mail pickup service by nl-irelay.cmg.nl with Microsoft SMTPSVC; Thu, 2 Nov 2000 20:32:21 +0100 Received: from loki.ietf.org ([132.151.1.177]) by nl-irelay.cmg.nl with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 16:02:18 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA26956 for ietf-123-outbound.09@ietf.org; Thu, 2 Nov 2000 08:45:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26115 for ; Thu, 2 Nov 2000 06:36:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16351; Thu, 2 Nov 2000 06:36:08 -0500 (EST) Message-Id: <200011021136.GAA16351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-02.txt Date: Thu, 02 Nov 2000 06:36:07 -0500 X-OriginalArrivalTime: 02 Nov 2000 15:02:19.0402 (UTC) FILETIME=[E56DE6A0:01C044DD] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-02.txt Pages : 62 Date : 01-Nov-00 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143738.I-D@ietf.org> --OtherAccess-- --NextPart-- --9B095B5ADSN=_01C044DC88685DA000000295nl?irelay.cmg.nl-- From owner-ietf-smime Fri Nov 3 07:30:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA01334 for ietf-smime-bks; Fri, 3 Nov 2000 07:30:17 -0800 (PST) Received: from mainserver.ps.gov.cn ([210.74.122.144]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01329 for ; Fri, 3 Nov 2000 07:30:14 -0800 (PST) Date: Fri, 3 Nov 2000 07:30:14 -0800 (PST) From: hv@of-hachetal.de Message-Id: <200011031530.HAA01329@ns.secondary.com> Received: from 1Cust239.tnt2.mia5.da.uu.net by mainserver.ps.gov.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id SXP0MWCJ; Fri, 3 Nov 2000 22:28:18 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-smime Sat Nov 4 06:44:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA16834 for ietf-smime-bks; Sat, 4 Nov 2000 06:44:15 -0800 (PST) Received: from mainserver.ps.gov.cn ([210.74.122.144]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16827 for ; Sat, 4 Nov 2000 06:44:10 -0800 (PST) Date: Sat, 4 Nov 2000 06:44:10 -0800 (PST) From: hv@of-hachetal.de Message-Id: <200011041444.GAA16827@ns.secondary.com> Received: from 1Cust239.tnt2.mia5.da.uu.net by mainserver.ps.gov.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id SXP0MWCJ; Fri, 3 Nov 2000 22:28:18 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-smime Sun Nov 5 10:18:23 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08378 for ietf-smime-bks; Sun, 5 Nov 2000 10:18:23 -0800 (PST) Received: from ns.vivanet.co.kr (IDENT:root@ns.vivanet.co.kr [210.207.57.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08373 for ; Sun, 5 Nov 2000 10:18:22 -0800 (PST) Received: from opdopd (01-024.044.popsite.net [64.24.244.24]) by ns.vivanet.co.kr (8.9.3/8.9.3) with ESMTP id DAA20081; Mon, 6 Nov 2000 03:47:00 +0900 Message-Id: <200011051847.DAA20081@ns.vivanet.co.kr> From: "Darrel" Subject: FIRE your BOSS... #6F16 To: win291d@ns.vivanet.co.kr X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 05 Nov 2000 11:59:49 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA08375 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are YOU... Tired of working for someone else and getting paid what "they" feel you're worth? Looking for a legitimate home-based enterprise that can generate you $2,000 & more weekly? ARE YOU READY FOR A CHANGE, AND WANT TO DEVELOP TRUE WEALTH IN YOUR LIFE? Are you looking for RESULTS and not hype? Here are the facts: *80% profit on all sales that pay you from $1250 to $6250 per sale *No personal selling or "convince me" tactics involved *Easy to follow, step by step, information system in place does the explaining for you *Not MLM or franchise *Full personal training and support *Lead generation system that BRINGS qualified prospects TO YOU *Multiple 6 figure income realistically attainable in 1st year *PROVEN 3 years to retirement program... PERIOD! If this sounds like what you are looking for then CALL NOW!!! 1-800-320-9895 ext 6172, 24 hr. recorded message system. Leave your name, phone number, and email address- twice!! After a brief 2 to 3 minute interview, I will get you all the information you need to make your own relaxed and intelligent decision about your future. Serious inquiries only please *********************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply to: mailto:dfbn@keromail.com?subject=remove ************************************************************ From owner-ietf-smime Mon Nov 6 03:25:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA22231 for ietf-smime-bks; Mon, 6 Nov 2000 03:25:03 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22227 for ; Mon, 6 Nov 2000 03:25:02 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12608; Mon, 6 Nov 2000 06:31:45 -0500 (EST) Message-Id: <200011061131.GAA12608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-x400wrap-00.txt Date: Mon, 06 Nov 2000 06:31:45 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400wrap-00.txt Pages : 9 Date : 03-Nov-00 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-x400wrap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-x400wrap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001103114317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001103114317.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Nov 6 03:25:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA22239 for ietf-smime-bks; Mon, 6 Nov 2000 03:25:07 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22234 for ; Mon, 6 Nov 2000 03:25:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12648; Mon, 6 Nov 2000 06:31:49 -0500 (EST) Message-Id: <200011061131.GAA12648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-x400transport-00.txt Date: Mon, 06 Nov 2000 06:31:49 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-00.txt Pages : 4 Date : 03-Nov-00 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-x400transport-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-x400transport-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001103114327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001103114327.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Nov 6 05:43:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA00351 for ietf-smime-bks; Mon, 6 Nov 2000 05:43:25 -0800 (PST) Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00345 for ; Mon, 6 Nov 2000 05:43:22 -0800 (PST) Received: (qmail 2218 invoked from network); 6 Nov 2000 13:50:01 -0000 Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 6 Nov 2000 13:50:01 -0000 Received: (qmail 11878 invoked from network); 6 Nov 2000 13:50:00 -0000 Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 6 Nov 2000 13:50:00 -0000 From: "William Ottaway" To: , Cc: Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt Date: Mon, 6 Nov 2000 13:54:46 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-reply-to: <200011061131.GAA12648@ietf.org> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Just a few comments on your draft. 1) "Expires in six months" is no longer acceptable. You have to put the expiry date at the front and end of the draft, egg 2nd May 2001. 2) Section 1: Insert "the" between "in" and "Cryptographic". 3) Section 2.1, para 2: replace "which is" with "wants to be" to read "... User Agent wants to be delivered to one or more recipients". 4) Section 2.3, id-ep-content: append "(2)" after "joint-iso-itu-t" 5) Section 2.4, last sentence: change to "Heterogeneous mail systems or other factors MAY require the presence of this outer MIME wrapper". Bill. From owner-ietf-smime Mon Nov 6 06:09:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02393 for ietf-smime-bks; Mon, 6 Nov 2000 06:09:22 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02386; Mon, 6 Nov 2000 06:09:21 -0800 (PST) Received: from ieca.com (mva-aa-064.capu.net [207.226.159.64]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA15291; Mon, 6 Nov 2000 09:15:59 -0500 Message-ID: <3A06BD1B.BE71F997@ieca.com> Date: Mon, 06 Nov 2000 09:15:55 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: William Ottaway CC: phoffman@imc.org, ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-x400transport-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I concur on these. Chris B. ______________________ William Ottaway wrote: > Hi, > > Just a few comments on your draft. > > 1) "Expires in six months" is no longer acceptable. You have to put the > expiry date at the front and end of the draft, egg 2nd May 2001. > > 2) Section 1: Insert "the" between "in" and "Cryptographic". > > 3) Section 2.1, para 2: replace "which is" with "wants to be" to read "... > User Agent wants to be delivered to one or more recipients". > > 4) Section 2.3, id-ep-content: append "(2)" after "joint-iso-itu-t" > > 5) Section 2.4, last sentence: change to "Heterogeneous mail systems or > other factors MAY require the presence of this outer MIME wrapper". > > Bill. From owner-ietf-smime Tue Nov 7 05:45:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA27200 for ietf-smime-bks; Tue, 7 Nov 2000 05:45:54 -0800 (PST) Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA27187 for ; Tue, 7 Nov 2000 05:45:52 -0800 (PST) Received: (qmail 1787 invoked from network); 7 Nov 2000 13:52:40 -0000 Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 7 Nov 2000 13:52:40 -0000 Received: (qmail 6602 invoked from network); 7 Nov 2000 13:52:39 -0000 Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 7 Nov 2000 13:52:39 -0000 From: "William Ottaway" To: Cc: , , Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt Date: Tue, 7 Nov 2000 13:57:29 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <200011061131.GAA12608@ietf.org> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Some observations :- 1) Replace "Expires in six months" with actual expiry date. 2) Section 1, first sentence: Insert "the" between "in" and "Cryptographic" 3) Section 1.1, para 2, second sentence. add "carrying X.400 content" before "," to read "In order to create S/MIME messages carrying X.400 content, an S/MIME ..." 4) Section 1.3, DER definition: replace "x" with "1" to read "8825-1" 5) Section 2.4, first sentence: Insert "the" between "of" and "ContentInfo". 6) Section 2.5, para 2, second sentence: replace "CMS/X400" with "CMS-X400" 7) Section 2.5, para 5: replace "CMS/X400" with "CMS-X400" 8) Section 3.1, para 3, first sentence: replace "which is" with "wants to be" to read "... User Agent wants to be delivered to one or more recipients." 9) Section 3.2, para 4, second sentence: Change to "If other 8-bit transports (e.g., X.400) are used then the optional MIME encoding SHOULD NOT be used." 10) Section 3.4 para 2, first sentence: Replace "is-data" with "id-data". 11) Section 3.6: Can you specify the standards within the PKIX WG that you are referring to? Bill. From owner-ietf-smime Fri Nov 10 00:24:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA02032 for ietf-smime-bks; Fri, 10 Nov 2000 00:24:09 -0800 (PST) Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA02024 for ; Fri, 10 Nov 2000 00:24:06 -0800 (PST) Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id ; Fri, 10 Nov 2000 08:31:08 -0000 Message-ID: <3130909C0878D4118010006008517A7C78E8@swordfish.nexor.co.uk> From: Graeme Lunt To: ietf-smime@imc.org Cc: "'j.onions@nexor.co.uk'" Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt Date: Fri, 10 Nov 2000 08:31:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Here are some comments on the following draft: > Title : Securing X.400 Content with S/MIME They relate to section 3.2. The use of the terms "signedData Element", "signedData object" and "signedData structure" seems a little confusing. As I read it: "signedData element" is the encapContentInfo(EncapsulatedContentInfo) field within "SignedData" "signedData structure" is the complete SignedData SEQUENCE and "signedData object" is the the ContentInfo SEQUENCE, with a contentType of id-signedData, containing the SignedData SEQUENCE If this is indeed correct, then the last sentence of para 2. should be made the first sentence of para 1. This would more closely follow the line of processing, and indicate the use of only one optional MIME encoding, the transport. Which raises another other point. In para 2, it states that: "X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be MIME wrapped). Surely this should be "MUST be ASN.1 encoded", especially given that the "content type of the protected X.400 content MUST be placed in the eContentType field". (The use of "SHOULD" is also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1 encoding for triple-wrapped messages). For example, if I find an eContentType of "2.6.1.10.1" (P22), I would expect the content to be ASN.1 encoded. Is there a reason why you would want to allow a different encoding of the X.400 content prior to protection, or is this just a typo? (In para 2, 3rd sentence you should add a "the", so as to read: "The object identifier for the content type ...") A similar set of comments apply to section 3.3 Graeme From owner-ietf-smime Fri Nov 10 00:42:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA04679 for ietf-smime-bks; Fri, 10 Nov 2000 00:42:34 -0800 (PST) Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04672 for ; Fri, 10 Nov 2000 00:42:33 -0800 (PST) Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id ; Fri, 10 Nov 2000 08:49:40 -0000 Message-ID: <3130909C0878D4118010006008517A7C78E9@swordfish.nexor.co.uk> From: Graeme Lunt To: ietf-smime@imc.org Cc: "'j.onions@nexor.co.uk'" Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt Date: Fri, 10 Nov 2000 08:49:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Here are some comments on the following draft: > Title : Transporting S/MIME Objects in X.400 The comments relate to section 2.2, and in particular to the OID for CMS objects than are MIME encoded. The proposal is to use a CMS-defined OID to indicate an S/MIME content type. However, would it not be better to use an OID that indicate MIME (rather than S/MIME)? The actual MIME type (and additional parameters) will be contained within the MIME headers, so that it is not essential to carry the actual type in the P1 envelope. There is very little an X.400 MTA would be able to deduce from the P1 content type alone, without examining the MIME headers. However, with the more generic approach I can carry arbitrary MIME types, including multipart/signed. Obviously, a more generic approach is not necessarily within the scope of the S/MIME group. Comments? Graeme From owner-ietf-smime Fri Nov 10 11:43:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01363 for ietf-smime-bks; Fri, 10 Nov 2000 11:43:14 -0800 (PST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01345; Fri, 10 Nov 2000 11:43:07 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3A0C4D95.2C35F39C@ieca.com> References: <3A0C4D95.2C35F39C@ieca.com> Date: Fri, 10 Nov 2000 11:50:14 -0800 To: "Bonatti, Chris" , William Ottaway From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt Cc: ietf-smime@imc.org, anders.eggen@ffi.no Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:33 PM -0500 11/10/00, Bonatti, Chris wrote: >Comment 11 asks for more specific references in PKIX. I assumed that this >referred to PKCS-10 and CRMF. No, it refers to CMP and CMC. Aren't multiple protocols for doing the same thing fun? :-) > My feeling here is that we should be as >non-specific as possible to avoid introducing any undesireably dependencies. The wording does not include any dependencies at all. That was quite purposeful in the S/MIME spec from which we copied this text. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri Nov 10 11:26:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00160 for ietf-smime-bks; Fri, 10 Nov 2000 11:26:44 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00153; Fri, 10 Nov 2000 11:26:42 -0800 (PST) Received: from ieca.com (mva-aa-077.capu.net [207.226.159.77]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id OAA19323; Fri, 10 Nov 2000 14:33:45 -0500 Message-ID: <3A0C4D95.2C35F39C@ieca.com> Date: Fri, 10 Nov 2000 14:33:41 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: William Ottaway CC: ietf-smime@imc.org, phoffman@imc.org, anders.eggen@ffi.no Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I concur on 1-8 and 10. Comment 9 seems gratuitous, but I don't object. Comment 11 asks for more specific references in PKIX. I assumed that this referred to PKCS-10 and CRMF. My feeling here is that we should be as non-specific as possible to avoid introducing any undesireably dependencies. I guess I'm not entirely comfortable with "at the time of this writing" either, but I could live with it. Chris B. _____________________ William Ottaway wrote: > Hi, > > Some observations :- > > 1) Replace "Expires in six months" with actual expiry date. > 2) Section 1, first sentence: Insert "the" between "in" and "Cryptographic" > 3) Section 1.1, para 2, second sentence. add "carrying X.400 content" before > "," to read "In order to create S/MIME messages carrying X.400 content, an > S/MIME ..." > 4) Section 1.3, DER definition: replace "x" with "1" to read "8825-1" > 5) Section 2.4, first sentence: Insert "the" between "of" and "ContentInfo". > 6) Section 2.5, para 2, second sentence: replace "CMS/X400" with "CMS-X400" > 7) Section 2.5, para 5: replace "CMS/X400" with "CMS-X400" > 8) Section 3.1, para 3, first sentence: replace "which is" with "wants to > be" to read "... User Agent wants to be delivered to one or more > recipients." > 9) Section 3.2, para 4, second sentence: Change to "If other 8-bit > transports (e.g., X.400) are used then the optional MIME encoding SHOULD NOT > be used." > 10) Section 3.4 para 2, first sentence: Replace "is-data" with "id-data". > 11) Section 3.6: Can you specify the standards within the PKIX WG that you > are referring to? > > Bill. From owner-ietf-smime Fri Nov 10 21:51:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA14177 for ietf-smime-bks; Fri, 10 Nov 2000 21:51:24 -0800 (PST) Received: from fw2-11.banamex.com.mx (firewall-user@na-40-173.na.avantel.net.mx [148.245.40.173] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA14173 for ; Fri, 10 Nov 2000 21:51:17 -0800 (PST) Received: by fw2-11.banamex.com.mx; id AAA03280; Sat, 11 Nov 2000 00:57:51 -0500 (EST) Message-Id: <200011110557.AAA03280@fw2-11.banamex.com.mx> Received: from nodnsquery(209.206.4.171) by fw2-11.banamex.com.mx via smap (V5.5) id xma003276; Fri, 10 Nov 00 23:57:32 -0600 From: "Barry Owen" Subject: You Can get Out #5874 To: debt84d@ragingbull.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Fri, 10 Nov 2000 23:39:50 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

"Reducing America's Debt!"

= Ask Yourself These 4 Questions=2E=2E=2E
Are monthly credit card = payments eating you alive?  Would you like to pay off y= our credit card & other unsecured debts in 12 -30 months?
Would you prefer to pay onl= y 2% of your unsecured debt per month?
(example: $10= ,000 debt =3D $200 monthly payment)		 Would you like to save 40-5= 0% of your total debt at the same time? 

= If You Answered YES to any of these questions
Then This= Program is for You=2E=2E=2E 

We can=2E=2E=2Ereduce your debt up to= 50%, cut your monthly payments by as much as 50%, totally eliminate your debt wi= thin 12 - 30 months, and direct you to a brighter more prosperous finan= cial future!
For your free consultation click here= !

Our goal is to negotiate with your creditors for the purpose of settli= ng the entire account balance at an amount significantly less than what i= s owed=2E Settlements are paid with moneys accumulated in your FDIC Insured Bank Account=2E You commit to a single monthly payment int= o the Program=2E As cash accumulates in the Your Account, settlement= offers are submitted to Creditors=2E Settlement agreements are ach= ieved as Creditors respond with counter offers, and then finalized by Your approval=2E

Settlements are often made in "bulk" (using financial le= verage and using pooled funds) securing discounts well beyond the capabil= ities of individual Consumers and most law firms=2E Preferred Financi= al Services successfully negotiates with Creditors nationwide=2E<= br>
You will receive monthly statements detailing your Account status = and negotiation activity pertaining to each debt=2E A truly unique asp= ect of our Program is that the You remain in control=2E You determine you= r own Monthly Payment Commitment; You determine the approximate amount of time it will take to complete the Program; Y= ou control how much money is withdrawn from the Your Bank Account; an= d You ultimately determine whether or not to accept a settlement=2E Our Debt Negoti= ation Program was truly developed with You in mind=2E

The Debt Negotiation Concept: 

The original concept of lowering or eliminating debt by negotiatio= n has been well established in the business to business arena for a numb= er of years prior to its adaptation to the general consumer market by a = group of Financial Planning Consultants=2E These consultants desired to = provide service for consumers unable to begin an investment plan due to hi= gh debt=2E Realizing consumers could be helped through debt mediation= , these Consultants began an investigation of consumer credit and debt specialists to whom they could refer Clients=2E The investigation = revealed many "not for profit" Credit Counseling Agencies claimin= g to represent the consumer while in reality these agencies were set up= to provide greater benefit to creditors=2E As a result of the investi= gation, these consultants (Preferred Financial Services) launched o= ne of the most progressive programs of its kind=2E  Until 1999, the program = was offered exclusively through professional Financial Planners and so= ld most often as part of an extensive financial planning package=2E O= ur Debt Negotiation Program is now offered directly to the general public,= helping countless individuals become debt free=2E

= Please take just 2 minutes to complete our free information request form=2E
You must be 18 to qualify and you must be a resident of the United States=2E
All information i= s held strictly confidential and will not be sold to any outside company=2E
How many times have you been more than 30 days late in paying your credit cards in the past 12 months?
Have you been late on your mortgage payments in the last 12 months?
Amount of credit card debt or unsecured debt?
Household Income?
I would like help with the following types of unsecured de= bt: (Note: We don't handle secured debt such as mortgages, e= quity loans, student loans or auto loans unless repossessed)
= Credit Cards
Medical Bills
Dept=2E Store Cards
Personal Lines of Credit
Personal Loans
Collection Accounts
   
Full Name:
Address:
City:
State:
Zip Code:
Day Phone:
Evening Phone:
Best Time To Call Y= ou:
Email Address:

List Removal/OPT-OUT Option
Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-ietf-smime Mon Nov 13 05:54:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA21504 for ietf-smime-bks; Mon, 13 Nov 2000 05:54:36 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21500 for ; Mon, 13 Nov 2000 05:54:35 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA13668; Mon, 13 Nov 2000 06:01:15 -0800 (PST) Message-Id: <4.3.2.7.2.20001110161730.01a45590@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Nov 2000 16:20:03 -0500 To: Graeme Lunt From: Russ Housley Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt Cc: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" In-Reply-To: <3130909C0878D4118010006008517A7C78E9@swordfish.nexor.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme: The CMS contentInfo uses id-data when the content is expected to be MIME. This choice is for historical reasons (S/MIME v2 did it that way). I think that the authors are trying to avoid a layer of MIME encapsulation. Did I miss something? Russ At 08:49 AM 11/10/2000 +0000, Graeme Lunt wrote: >Hi, > >Here are some comments on the following draft: > > Title : Transporting S/MIME Objects in X.400 > >The comments relate to section 2.2, and in particular to the >OID for CMS objects than are MIME encoded. > >The proposal is to use a CMS-defined OID to indicate an >S/MIME content type. However, would it not be better to use >an OID that indicate MIME (rather than S/MIME)? > >The actual MIME type (and additional parameters) will be contained >within the MIME headers, so that it is not essential to carry the >actual type in the P1 envelope. There is very little an X.400 MTA >would be able to deduce from the P1 content type alone, without >examining the MIME headers. > >However, with the more generic approach I can carry arbitrary MIME >types, including multipart/signed. Obviously, a more generic approach >is not necessarily within the scope of the S/MIME group. > >Comments? > >Graeme From owner-ietf-smime Mon Nov 13 08:05:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04361 for ietf-smime-bks; Mon, 13 Nov 2000 08:05:50 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04357 for ; Mon, 13 Nov 2000 08:05:48 -0800 (PST) Received: from ieca.com (mva-aa-034.capu.net [207.226.159.34]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA17894; Mon, 13 Nov 2000 11:12:55 -0500 Message-ID: <3A101303.9EEB20FD@ieca.com> Date: Mon, 13 Nov 2000 11:12:51 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Russ Housley CC: Graeme Lunt , ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: Re: I-D ACTION:draft-ietf-smime-x400transport-00.txt References: <4.3.2.7.2.20001110161730.01a45590@mail.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, That was certainly my thinking as we assembled this. Plus, there is the added issue that I don't think there is an OID defined for MIME in the Internet mail standards (old or new). It seems that 'id-data' is all there is. Chris ____________________ Russ Housley wrote: > Graeme: > > The CMS contentInfo uses id-data when the content is expected to be > MIME. This choice is for historical reasons (S/MIME v2 did it that way). > > I think that the authors are trying to avoid a layer of MIME > encapsulation. Did I miss something? > > Russ > > At 08:49 AM 11/10/2000 +0000, Graeme Lunt wrote: > >Hi, > > > >Here are some comments on the following draft: > > > Title : Transporting S/MIME Objects in X.400 > > > >The comments relate to section 2.2, and in particular to the > >OID for CMS objects than are MIME encoded. > > > >The proposal is to use a CMS-defined OID to indicate an > >S/MIME content type. However, would it not be better to use > >an OID that indicate MIME (rather than S/MIME)? > > > >The actual MIME type (and additional parameters) will be contained > >within the MIME headers, so that it is not essential to carry the > >actual type in the P1 envelope. There is very little an X.400 MTA > >would be able to deduce from the P1 content type alone, without > >examining the MIME headers. > > > >However, with the more generic approach I can carry arbitrary MIME > >types, including multipart/signed. Obviously, a more generic approach > >is not necessarily within the scope of the S/MIME group. > > > >Comments? > > > >Graeme From owner-ietf-smime Mon Nov 13 08:15:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04682 for ietf-smime-bks; Mon, 13 Nov 2000 08:15:35 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04678 for ; Mon, 13 Nov 2000 08:15:33 -0800 (PST) Received: from ieca.com (mva-aa-050.capu.net [207.226.159.50]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA18786; Mon, 13 Nov 2000 11:22:50 -0500 Message-ID: <3A101556.9295D1ED@ieca.com> Date: Mon, 13 Nov 2000 11:22:46 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Graeme Lunt CC: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt References: <3130909C0878D4118010006008517A7C78E8@swordfish.nexor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme Lunt wrote: > Which raises another other point. In para 2, it states that: > "X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be > MIME wrapped). Surely this should be "MUST be ASN.1 encoded", > especially given that the "content type of the protected X.400 content > MUST be placed in the eContentType field". (The use of "SHOULD" is > also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1 > encoding for triple-wrapped messages). > > For example, if I find an eContentType of "2.6.1.10.1" (P22), I would > expect the content to be ASN.1 encoded. > Is there a reason why you would want to allow a different encoding of > the X.400 content prior to protection, or is this just a typo? > Graeme, I'm going to have to check up on your other comments, but this one has an immediate answer. The reason that the ASN.1 encoding is a SHOULD and not a MUST is that X.400 allows non-ASN.1 content. Obviously P22 is not in this category, but we did not want to unnecessarily exclude the applicability of the specification. Neither the 'eContent' nor 'encryptedContent' fields in CMS should have any trouble with this. They are both defined as OCTET STRING, and should be able to handle any data regardless of encoding. The chief reasons that we mandated an encoding here in RFC 2633 were (a) backward compatibility, and (b) MIME processors rely on this wrapper to tell it what the content is. Neither of these reasons seemed to apply with X.400 content. Chris From owner-ietf-smime Mon Nov 13 12:48:33 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA20650 for ietf-smime-bks; Mon, 13 Nov 2000 12:48:33 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20646 for ; Mon, 13 Nov 2000 12:48:32 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA20693 for ; Mon, 13 Nov 2000 12:55:20 -0800 (PST) Message-Id: <4.3.2.7.2.20001113134837.01a45838@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Nov 2000 13:50:19 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: draft-ietf-smime-idea-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: I believe that this takes care of all of the issues raised during working group Last Call. Did I miss anything? Russ From owner-ietf-smime Mon Nov 13 22:27:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA02367 for ietf-smime-bks; Mon, 13 Nov 2000 22:27:03 -0800 (PST) Received: from mail.izigi.co.kr (IDENT:root@[211.112.1.166]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02357 for ; Mon, 13 Nov 2000 22:26:55 -0800 (PST) Received: from vhfgerw (01-021.044.popsite.net [64.24.244.21]) by mail.izigi.co.kr (8.9.3/8.9.3) with ESMTP id WAA06558; Mon, 13 Nov 2000 22:11:54 +0900 Message-Id: <200011131311.WAA06558@mail.izigi.co.kr> From: "Sam Kinser" Subject: Big Win #3AAF To: net39s@mail.izigi.co.kr X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Mon, 13 Nov 2000 05:29:55 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA02362 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:gm99t@cmpmail.com?subject=more_info //////////////////////////////////////////////////// Please remove at: mailto:bak29@mail1st.com?subject=remove //////////////////////////////////////////////////// From owner-ietf-smime Mon Nov 13 23:23:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA10361 for ietf-smime-bks; Mon, 13 Nov 2000 23:23:28 -0800 (PST) Received: from alpha.it-sec.com (alpha.it-sec.com [195.141.254.202] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10341 for ; Mon, 13 Nov 2000 23:23:24 -0800 (PST) Received: from svzh0004.itsec.ch (localhost [127.0.0.1]) by alpha.it-sec.com (8.9.3/8.9.3) with ESMTP id IAA14143; Tue, 14 Nov 2000 08:28:20 +0100 (MET) Received: by SVZH0004 with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Nov 2000 08:29:20 +0100 Message-ID: From: "Teiwes, Stephan (iT_SEC)" To: "'Russ Housley'" , ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea-08.txt Date: Tue, 14 Nov 2000 08:29:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi draft-ietf-smime-idea-08.txt has been modified considering the comments of M. Masiutin, RIT Research Labs. *Stephan Teiwes, iT_Security AG -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Montag, 13. November 2000 19:50 To: ietf-smime@imc.org Subject: draft-ietf-smime-idea-08.txt All: I believe that this takes care of all of the issues raised during working group Last Call. Did I miss anything? Russ >From: "Teiwes, Stephan (iT_SEC)" >To: "'Maxim Masiutin'" , > "Teiwes, Stephan (iT_SEC)" > , > "Hartmann, Peter (iT_SEC)" > , > diego.kuenzi@it-sec.com, ietf-pkix@imc.org >Subject: RE: Use of the IDEA Encryption Algorithm in CMS >Date: Mon, 23 Oct 2000 16:52:21 +0200 >X-Mailer: Internet Mail Service (5.5.2448.0) >List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ >List-ID: >List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > >Dear Mr. Masuitin, > >thanks a lot. We'll consider your comments and try to improve the draft >accordingly. > >*Stephan Teiwes >iT_Security AG >www.it-sec.com > >-----Original Message----- >From: Maxim Masiutin [mailto:max@ritlabs.com] >Sent: Montag, 23. Oktober 2000 16:41 >To: stephan.teiwes@it-sec.com; peter.hartmann@it-sec.com; >diego.kuenzi@it-sec.com; ietf-pkix@imc.org >Subject: Use of the IDEA Encryption Algorithm in CMS > > >Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft! > > >I have a question about following paragraph in >draft-ietf-smime-idea-07.txt: > >----------- >If IV is specified as above, it MUST be used as initial vector. In >this case, the ciphertext MUST NOT include the initial vector. If >IV is not specified, the first 64 bits of the ciphertext MUST be >considered as the initial vector. However, this alternative of not >including the IV SHOULD NOT be applied in CMS or S/MIME. >----------- > > The last sentence: > >"this alternative of not including the IV [into "iv OCTET STRING" of >IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be >applied in CMS or S/MIME. > > >Could you please expand this sentence by adding one of the short >explanations that I've proposed? > >I do also have a question about the following paragraph: > >------------ >The SMIMECapability SEQUENCE representing the IDEA symmetric >encryption algorithm MUST include the IDEA-CBC OID in the capabilityID >field and the parameters field MUST be absent. The SMIMECapability >SEQUENCE for IDEA encryption SHOULD be included in the symmetric >encryption algorithms portion of the SMIMECapabilities list. The >SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as >follows: 300D 060B 2B06 0104 0181 3C07 0101 02. >------------ > > Why don't you give ASN.1 notation of SMIMECapability SEQUENCE > representing IDEA as well as DER-encoded value? Please add ASN.1 > notation to the draft. Also, please clarify the byte order. > > And a test sample of CMS-message with IDEA will help me a lot! > > Thank you in advance. > > > >-- >Maxim Masiutin, >Software Engineer >RIT Research Labs http://www.ritlabs.com/ From owner-ietf-smime Tue Nov 14 03:37:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11474 for ietf-smime-bks; Tue, 14 Nov 2000 03:37:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11470 for ; Tue, 14 Nov 2000 03:37:33 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09951; Tue, 14 Nov 2000 06:44:58 -0500 (EST) Message-Id: <200011141144.GAA09951@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-08.txt Date: Tue, 14 Nov 2000 06:44:58 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the IDEA Encryption Algorithm in CMS Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-08.txt Pages : 6 Date : 13-Nov-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001113134829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001113134829.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Tue Nov 14 03:12:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA09641 for ietf-smime-bks; Tue, 14 Nov 2000 03:12:13 -0800 (PST) Received: from post.ffi.no (post.ffi.no [193.156.99.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09626; Tue, 14 Nov 2000 03:12:03 -0800 (PST) Received: by post.ffi.no with Internet Mail Service (5.5.2650.21) id <40130J4A>; Tue, 14 Nov 2000 12:19:15 +0100 Message-ID: <4B11D7CAB78AD2119BC100A0C9EA88EC445764@post.ffi.no> From: Anders Eggen To: "'Graeme Lunt'" , ietf-smime@imc.org Cc: "'BonattiC@ieca.com'" , "'phoffman@imc.org'" Subject: SV: I-D ACTION:draft-ietf-smime-x400wrap-00.txt Date: Tue, 14 Nov 2000 12:19:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04E2C.B8FAF65A" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04E2C.B8FAF65A Content-Type: text/plain; charset="iso-8859-1" Graeme, >Here are some comments on the following draft: > Title : Securing X.400 Content with S/MIME >They relate to section 3.2. > >The use of the terms "signedData Element", "signedData object" and >"signedData structure" seems a little confusing. As I read it: > >"signedData element" is the encapContentInfo(EncapsulatedContentInfo) >field within "SignedData" > >"signedData structure" is the complete SignedData SEQUENCE > >and > >"signedData object" is the the ContentInfo SEQUENCE, with a >contentType of id-signedData, containing the SignedData SEQUENCE > >If this is indeed correct, then the last sentence of para 2. should >be made the first sentence of para 1. This would more closely follow >the line of processing, and indicate the use of only one optional >MIME encoding, the transport. >Which raises ............. A similar set of comments apply to section 3.3 Graeme I understand that this may seem a little confusing. To make this clearer throughout the chapter, I propose that we do the following (underlined) changes: * The first paragraph of section 3.2 should be: "The SignedData format as described in the ......" * The second paragraph of section 3.2 should be: "The protected X.400 content MUST then be placed in the SignedData encapContentInfo eContent field. Note that this X.400 content SHOULD be ASN.1 encoded, but SHOULD NOT be MIME wrapped. The object identifier for the content type of the protected X.400 content MUST be placed in the SignedData encapContentInfo eContentType field. The resulting signedData object MAY optionally be wrapped in a MIME encoding." * The third paragraph of section 3.2 should be: "The signedData object is encapsulated by a ........" * The step 2 in section 3.2.1. shoul be: "Step 2. The ASN.1 encoded X.400 content and other required data is processed into a CMS object of type SignedData." * The second paragraph of section 3.3 should be: "The EnvelopedData format as described in the............." * The third paragraph of section 3.3 should be: "The protected X.400 content MUST be placed in the EnvelopedData encryptedContentInfo encryptedContent field. Note that this X.400 content should be ASN.1 encoded, but should not be MIME wrapped. The object identifier for content type of the protected X.400 content MUST be placed in the EnvelopedData encryptedContentInfo contentType field. The resulting envelopedData object MAY optionally be wrapped in a MIME encoding. * The fouth paragraph of section 3.3 should be: "The envelopedData object is encapsulated by ......." * The first sentence of step 2 in section 3.3.1 shoul be: "The ASN.1 encoded X.400 content and other required data is processed into a CMS object of type EnvelopedData. * The steps of the tripple wrapping in section 3.4.1 should be written as; step 1, step 2 ..., and not just marked with numbers. * The first sentence of step 2 in section 3.4.1 shoul be: "Step 2. Place the protected ASN.1 encoded X.400 content in the SignedData encapContentInfo eContent field. Anders Eggen > -----Opprinnelig melding----- > Fra: Graeme Lunt [SMTP:g.lunt@nexor.co.uk] > Sendt: Friday, November 10, 2000 9:31 AM > Til: ietf-smime@imc.org > Kopi: 'j.onions@nexor.co.uk' > Emne: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt > > Hi, > > Here are some comments on the following draft: > > Title : Securing X.400 Content with S/MIME > > They relate to section 3.2. > > The use of the terms "signedData Element", "signedData object" and > "signedData structure" seems a little confusing. As I read it: > > "signedData element" is the encapContentInfo(EncapsulatedContentInfo) > field within "SignedData" > > "signedData structure" is the complete SignedData SEQUENCE > > and > > "signedData object" is the the ContentInfo SEQUENCE, with a > contentType of id-signedData, containing the SignedData SEQUENCE > > If this is indeed correct, then the last sentence of para 2. should > be made the first sentence of para 1. This would more closely follow > the line of processing, and indicate the use of only one optional > MIME encoding, the transport. > > Which raises another other point. In para 2, it states that: > "X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be > MIME wrapped). Surely this should be "MUST be ASN.1 encoded", > especially given that the "content type of the protected X.400 content > MUST be placed in the eContentType field". (The use of "SHOULD" is > also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1 > encoding for triple-wrapped messages). > > For example, if I find an eContentType of "2.6.1.10.1" (P22), I would > expect the content to be ASN.1 encoded. > Is there a reason why you would want to allow a different encoding of > the X.400 content prior to protection, or is this just a typo? > > (In para 2, 3rd sentence you should add a "the", so as to read: > "The object identifier for the content type ...") > > A similar set of comments apply to section 3.3 > > Graeme ------_=_NextPart_001_01C04E2C.B8FAF65A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SV: I-D ACTION:draft-ietf-smime-x400wrap-00.txt

Graeme,

>Here are some comments on the following draft:
>       = Title           : Securing = X.400 Content with S/MIME
>They relate to section 3.2.
>
>The use of the terms "signedData Element", = "signedData object" and
>"signedData structure" seems a little = confusing. As I read it:
>
>"signedData element" is the = encapContentInfo(EncapsulatedContentInfo)
>field within "SignedData"
>
>"signedData structure" is the complete = SignedData SEQUENCE
>
>and
>
>"signedData object" is the the ContentInfo = SEQUENCE, with a
>contentType of id-signedData, containing the SignedData = SEQUENCE
>
>If this is indeed correct, then the last sentence of = para 2. should
>be made the first sentence of para 1. This would more = closely follow
>the line of processing, and indicate the use of only one = optional
>MIME encoding, the transport.

>Which raises .............

    A similar set of comments apply to = section 3.3

    Graeme


I understand that = this may seem a little confusing. To make this clearer throughout the = chapter, I propose that we do the following (underlined) = changes:


  • The first = paragraph of section 3.2 should be:

    • "The = SignedData format as described in the ......"

  • The second = paragraph of section 3.2 should be:

    • "The protected = X.400 content MUST then be placed in the SignedData encapContentInfo eContent = field. Note = that this X.400 content SHOULD be ASN.1 encoded, but SHOULD NOT be MIME = wrapped. The object identifier for the content type of the protected = X.400 content MUST be placed in the SignedData encapContentInfo eContentType field.  The resulting = signedData object MAY optionally be wrapped in a MIME = encoding."

  • The third paragraph = of section 3.2 should be:

    • "The = signedData object is encapsulated by a ........"

  • The step 2 in = section 3.2.1. shoul be:

    • "Step 2. The = ASN.1 encoded X.400 content and other required data is
    processed into a = CMS object of type SignedData."

  • The second = paragraph of section 3.3 should be:

    • "The = EnvelopedData format as = described in the............."

  • The third paragraph = of section 3.3 should be:

    • "The protected = X.400 content MUST be placed in the EnvelopedData encryptedContentInfo = encryptedContent field. Note that this X.400 content should be ASN.1 encoded, = but should not be MIME wrapped. The object identifier for content type = of the protected X.400 content MUST be placed in the EnvelopedData = encryptedContentInfo contentType field. The resulting envelopedData = object MAY optionally be wrapped in a MIME encoding.

  • The fouth paragraph = of section 3.3 should be:

    • "The = envelopedData object is encapsulated by ......."

  • The first sentence = of step 2 in section 3.3.1 shoul be:

    • "The ASN.1 = encoded X.400 content and other required data is processed into a CMS = object of type EnvelopedData.

  • The steps of the = tripple wrapping in section 3.4.1 should be written as; step 1, step 2 = ..., and not just marked with numbers.

  • The first sentence = of step 2 in section 3.4.1 shoul be:

    • "Step 2. Place the protected ASN.1 encoded X.400 content in = the SignedData encapContentInfo eContent field.



Anders Eggen





    -----Opprinnelig melding-----
    Fra:    = Graeme Lunt = [SMTP:g.lunt@nexor.co.uk]
    Sendt:  Friday, November 10, 2000 9:31 AM
    Til:    = ietf-smime@imc.org
    Kopi:   'j.onions@nexor.co.uk'
    Emne:   RE: I-D = ACTION:draft-ietf-smime-x400wrap-00.txt

    Hi,

    Here are some comments on the = following draft:
    >       = Title           : Securing = X.400 Content with S/MIME

    They relate to section 3.2.

    The use of the terms "signedData = Element", "signedData object" and
    "signedData structure" = seems a little confusing. As I read it:

    "signedData element" is the = encapContentInfo(EncapsulatedContentInfo)
    field within = "SignedData"

    "signedData structure" is = the complete SignedData SEQUENCE

    and

    "signedData object" is the = the ContentInfo SEQUENCE, with a
    contentType of id-signedData, = containing the SignedData SEQUENCE

    If this is indeed correct, then the = last sentence of para 2. should
    be made the first sentence of para 1. = This would more closely follow
    the line of processing, and indicate = the use of only one optional
    MIME encoding, the transport.

    Which raises another other point. In = para 2, it states that:
    "X.400 content SHOULD be ASN.1 = encoded" (and consequently MUST NOT be
    MIME wrapped). Surely this should be = "MUST be ASN.1 encoded",
    especially given that the = "content type of the protected X.400 content
    MUST be placed in the eContentType = field". (The use of "SHOULD" is
    also somewhat at variance with step 1 = in 3.4.1 which mandates ASN.1
    encoding for triple-wrapped = messages).

    For example, if I find an eContentType = of "2.6.1.10.1" (P22), I would
    expect the content to be ASN.1 = encoded.
    Is there a reason why you would want = to allow a different encoding of
    the X.400 content prior to = protection, or is this just a typo?

    (In para 2, 3rd sentence you should = add a "the", so as to read:
    "The object identifier for the = content type ...")

    A similar set of comments apply to = section 3.3

    Graeme

------_=_NextPart_001_01C04E2C.B8FAF65A-- From owner-ietf-smime Thu Nov 16 02:34:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA11893 for ietf-smime-bks; Thu, 16 Nov 2000 02:34:38 -0800 (PST) Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11869 for ; Thu, 16 Nov 2000 02:34:34 -0800 (PST) Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id ; Thu, 16 Nov 2000 10:41:51 -0000 Message-ID: <3130909C0878D4118010006008517A7C02112C@swordfish.nexor.co.uk> From: Graeme Lunt To: "'Russ Housley'" Cc: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt Date: Thu, 16 Nov 2000 10:41:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > The CMS contentInfo uses id-data when the content is expected to be > MIME. This choice is for historical reasons (S/MIME v2 did > it that way). > > I think that the authors are trying to avoid a layer of MIME > encapsulation. Yes - I can see that you would want to avoid this. > Did I miss something? My comment was a little different. What is being proposed is that the OID id-data must be used for the X.400 content type when the CMS object is covered by an outer MIME wrapper. However, a more generic option is to use an OID (say "id-mime") for the X.400 content type that represents MIME. Using this content type I could still carry my MIME wrapped CMS object, but I could also carry other arbitray MIME objects. For example, I could carry multipart/signed with this method. In fact, thinking about it a little more, does the draft as it stands actually allow me to do this? If I use id-data as the content-type, MUST the content be a MIME wrapped CMS object? Could it just be arbitrary MIME? This would certainly be a useful feature. Graeme From owner-ietf-smime Thu Nov 16 02:45:45 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA15263 for ietf-smime-bks; Thu, 16 Nov 2000 02:45:45 -0800 (PST) Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15252 for ; Thu, 16 Nov 2000 02:45:43 -0800 (PST) Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id ; Thu, 16 Nov 2000 10:53:01 -0000 Message-ID: <3130909C0878D4118010006008517A7C02112D@swordfish.nexor.co.uk> From: Graeme Lunt To: "'Bonatti, Chris'" Cc: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt Date: Thu, 16 Nov 2000 10:53:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, > I'm going to have to check up on your other comments, but > this one has an immediate answer. The reason that the ASN.1 > encoding is a SHOULD and not a MUST is that X.400 allows > non-ASN.1 content. Fair point! Maybe a better wording is to say that: "this X.400 content SHOULD maintain the encoding defined by the content type" rather than implying that an ASN.1 encoding should be used if possible? Graeme From owner-ietf-smime Thu Nov 16 03:20:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27317 for ietf-smime-bks; Thu, 16 Nov 2000 03:20:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27296 for ; Thu, 16 Nov 2000 03:20:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09214; Thu, 16 Nov 2000 06:28:19 -0500 (EST) Message-Id: <200011161128.GAA09214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-02.txt Date: Thu, 16 Nov 2000 06:28:19 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the RSAES-OAEP Transport Algorithm in CMS Author(s) : R. Housley Filename : draft-ietf-smime-cms-rsaes-oaep-02.txt Pages : 8 Date : 15-Nov-00 This document describes the use of the RSAES-OAEP key transport method of key management within the Cryptographic Message Syntax [CMS]. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cms-rsaes-oaep-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001115091809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsaes-oaep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001115091809.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Nov 16 06:36:46 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26998 for ietf-smime-bks; Thu, 16 Nov 2000 06:36:46 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26989 for ; Thu, 16 Nov 2000 06:36:44 -0800 (PST) Received: from ieca.com (mva-aa-005.capu.net [207.226.159.5]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA19636; Thu, 16 Nov 2000 09:44:11 -0500 Message-ID: <3A13F2B6.C5C8E449@ieca.com> Date: Thu, 16 Nov 2000 09:44:06 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Graeme Lunt CC: "'Russ Housley'" , ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: Re: I-D ACTION:draft-ietf-smime-x400transport-00.txt References: <3130909C0878D4118010006008517A7C02112C@swordfish.nexor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme Lunt wrote: > In fact, thinking about it a little more, does the draft as it stands > actually allow me to do this? If I use id-data as the content-type, > MUST the content be a MIME wrapped CMS object? Could it just be arbitrary > MIME? > > This would certainly be a useful feature. > Graeme, I think that 'id-data' covers any MIME object, not just CMS. Since it's defined in the S/MIME standards, the door is certainly open for somebody to question the scope of its use as a generally applicable identifier for all MIME. However, since (to my knowledge) nothing like this exists elsewhere, it's the best choice available. Chris From owner-ietf-smime Thu Nov 16 06:32:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25989 for ietf-smime-bks; Thu, 16 Nov 2000 06:32:38 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25980 for ; Thu, 16 Nov 2000 06:32:35 -0800 (PST) Received: from ieca.com (mva-aa-124.capu.net [207.226.159.124]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA19248; Thu, 16 Nov 2000 09:40:02 -0500 Message-ID: <3A13F1BD.57D18C41@ieca.com> Date: Thu, 16 Nov 2000 09:39:57 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Graeme Lunt CC: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-00.txt References: <3130909C0878D4118010006008517A7C02112D@swordfish.nexor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme Lunt wrote: > Maybe a better wording is to say that: > > "this X.400 content SHOULD maintain the encoding defined by the > content type" > > rather than implying that an ASN.1 encoding should be used if > possible? > Okay, that makes good sense. Chris From owner-ietf-smime Thu Nov 16 07:56:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25303 for ietf-smime-bks; Thu, 16 Nov 2000 07:56:38 -0800 (PST) Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25276 for ; Thu, 16 Nov 2000 07:56:33 -0800 (PST) Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2650.14) id ; Thu, 16 Nov 2000 16:03:58 -0000 Message-ID: <3130909C0878D4118010006008517A7C021136@swordfish.nexor.co.uk> From: Graeme Lunt To: "'Bonatti, Chris'" Cc: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt Date: Thu, 16 Nov 2000 16:03:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Graeme, > > I think that 'id-data' covers any MIME object, not just > CMS. Since it's defined in the S/MIME standards, the door > is certainly open for somebody to question the scope of its > use as a generally applicable identifier for all > MIME. However, since (to my knowledge) nothing like this > exists elsewhere, it's the best choice available. OK - that's good - that's clarified it for me. I'm not sure if this could be commented on in the draft, maybe in the context of carrying multipart/signed? If so, something like: "If a multipart/signed message is to be transported in X.400, the CMS-defined value id-data SHOULD be used in the content-type field of the P1 envelope." after the definition of id-data in section 2.2? However, you may not want to do this if the draft is just looking at transporting CMS objects, or do want start down the road of addressing transporting generic MIME in this draft. Graeme From owner-ietf-smime Sat Nov 18 02:14:37 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17511 for ietf-smime-bks; Sat, 18 Nov 2000 02:14:37 -0800 (PST) Received: from starlink.co.kr ([203.242.202.130]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17493 for ; Sat, 18 Nov 2000 02:14:34 -0800 (PST) Message-Id: <200011181014.CAA17493@ns.secondary.com> Received: from [38.26.242.229] by starlink.co.kr (SMTPD32-3.04) id A8086740220; Sat, 18 Nov 2000 19:20:56 +0900 From: "Edward Kopen" Subject: Get rid of your "LOVE HANDLES' in 24 hours... # 1A0 To: nop20xc X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Fri, 17 Nov 2000 21:58:36 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA17499 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: JUST IN TIME FOR THE HOLIDAYS!!!!!! It only takes an hour of your time to gently rub in our miracle gel and .. LOSE 4-6 INCHES OF STUBBORN FAT OVERNIGHT! ****FLATTEN your stomach. ****RE-SHAPE your butt. ****TRIM your thighs. ****REDUCE cellulite everywhere! ^^^WITHOUT strict diets ^^^WITHOUT strenuous exercise ^^^WITHOUT harmful metabolism boosters ^^^WITHOUT expensive surgery Do you want to... [ ] GET SLIM for the Holidays & STAY SLIM? [ ] EAT WHAT YOU WANT at Holiday feasts and festivities but GET RID OF those extra inches FAST? [ ] BEGIN THE NEW YEAR without having to go on ANOTHER DIET? YOU CAN DO IT ALL!!!!! with the safe and reliable overnight results of our MIRACLE GEL. It's safe to use as often as once a week to help you lose more and more inches OR... to lose the added inches of too much Holiday celebrating! GUARANTEED RESULTS! "My wife was scheduled for $6,000 liposuction surgery. We saw your ad and decided your product was worth trying first. Words can't express our delight! My wife lost four inches in her midriff and three inches in her waist, much more than the 'average results' in your ad. Needless to say, we cancelled the surgery." Eric Larsen, Lacrosse, WI "I'm a professional singer, and I'm on the road a lot. I lost almost two inches in my waistline in the first 24 hours. I am very proud of the fact that I have lost this waistline and obliques fat." David Hutchins, Hickory, NC "I lost one inch in my waist, one inch in my hips, and two inches in my thighs. The overnight results with your product are really great! Thank you!" Susan Meir, New York, NY FOR MORE FREE INFORMATION, lots of testimonials, and a step-by-step description of how this product safely creates such amazing overnight results Reply To: mailto:sabt@usa.com?subject=more_info CALL US: 520-203-4572 (9am-6pm, MST Mon-Sun) You'll talk to people who have used our miracle gels. /////////////////////////////////////////////////////// Please remove at: mailto:kr21g@angelfire.com?subject=remove /////////////////////////////////////////////////////// From owner-ietf-smime Sun Nov 19 15:05:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA00577 for ietf-smime-bks; Sun, 19 Nov 2000 15:05:16 -0800 (PST) Received: from unknown ([198.211.237.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA00573; Sun, 19 Nov 2000 15:05:13 -0800 (PST) From: redial@wongfaye.com Subject: toner cartridges Date: Wed, 19 Nov 1997 14:28:02 Message-Id: <400.389117.88183@> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Toner Supplies at discount prices Laser Printer Toner Cartridges Fax and Copier Cartridges Order by phone:1-888-288-9043 Order by fax: 1-888-977-1577 *** E-mail removal line: 1-888-248-4930 *** *** If you would like to mail your order please call 1-888-248-2015 *** Pay by check, credit card or Purchase Order. If your order is by check please leave your check number (Mail check when you recieve merchandise) If your order is by credit card please leave your card number + expiration date If your order is by P.O. please leave your shipping/billing addresses Current Prices are as follows: Cartridges for Hewlett Packard printers: 4L,4p,1100 and series 2 cartridges are now $49 2p cartridges are $54 3si cartridges are $75 4000 and 2100 cartridges are $79 5000 and 8100 cartridges are $135 5p, 6p, 5mp and 6mp cartridges are $59 Cartridges for Apple printers Pro 600 or 16-600 cartridges are now $69 Laser writer select 300,320 and 360 cartridges are $69 Laser writer 300 and 320 cartridges are $54 Laser writer NT, 2nt, 2f, 2g and LS cartridges are $54 Laser writer personal 12-640 cartridges are $79 Cartridges for Hewlett Packard laser fax printers: Laser fax 500,700,5000,7000,fx1 and fx2 cartridges are now $59 Laser fax fx3 cartridges are $69 Our laser fax fx4 cartridges are $79 Cartridges for Lexmark and IBM printers Optra 4019 and 4029 are now $125 optra r,r+ and optra s cartridges are $135 optra e cartridges are $59 Our cartridges for canon copiers PC 3, 6re, 7 and 11 (A30) are now $69 PC 300,320,700,720 and 760 (E-40) are $89 90 day extended warranty included on all products. From owner-ietf-smime Tue Nov 21 07:09:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14950 for ietf-smime-bks; Tue, 21 Nov 2000 07:09:48 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14946 for ; Tue, 21 Nov 2000 07:09:46 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA15177 for ; Tue, 21 Nov 2000 07:10:05 -0800 (PST) Message-Id: <5.0.1.4.2.20001121100815.027ad180@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 21 Nov 2000 10:10:05 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: S/MIME WG Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Our tentative meeting slot for the upcoming meeting in San Diego was just announced. WEDNESDAY, 13 December 2000 from 1530 to 1730 SEC smime S/MIME Mail Security WG APP webdav WWW Distributed Authoring and Versioning WG INT frnetmib Frame Relay Service MIB WG OPS sls Service Level Specification and Usage BOF OPS sming Next Generation Structure of Man agement Information BOF RTG idr Internet-Domain Routing WG TSV avt Audio/Video Transport WG TSV seamoby SeaMoby BOF I will be posting a proposed agenda for the two hours soon. Russ From owner-ietf-smime Wed Nov 22 02:36:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17558 for ietf-smime-bks; Wed, 22 Nov 2000 02:36:07 -0800 (PST) Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17539 for ; Wed, 22 Nov 2000 02:36:03 -0800 (PST) Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Wed, 22 Nov 2000 10:38:38 +0000 Received: from ahmed (ahmed.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id KAA22948 for ; Wed, 22 Nov 2000 10:38:36 GMT From: "Ahmed Bhamjee" To: Subject: S/MIME v3 implementations Date: Wed, 22 Nov 2000 10:35:32 -0000 Message-ID: <000001c0546f$f170f9f0$c42078c1@sse.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.0.1.4.2.20001121100815.027ad180@mail.spyrus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Disposition-Notification-To: "Ahmed Bhamjee" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Could someone please provide me (or point me to a location where I can find) a list of products which implement Diffie-Hellman as per RFC 2631. Also, when using Diffie-Hellman Ephemeral-Static mode, what key size do you use to generate a new key pair. You could use the key size of the recipient, but what if you are sending the same message to multiple recipients who may have different DH key sizes. Another option is to use the size of your own static DH key pair. I would appreciate any advice or help with this. Thanks in advance Ahmed From owner-ietf-smime Wed Nov 22 08:11:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15393 for ietf-smime-bks; Wed, 22 Nov 2000 08:11:44 -0800 (PST) Received: from thehub.knight-hub.com (thehub.knight-hub.com [205.177.16.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15388 for ; Wed, 22 Nov 2000 08:11:42 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (va.spyrus.com [205.177.169.194]) by thehub.knight-hub.com (8.9.3/8.9.3) with ESMTP id LAA18074; Wed, 22 Nov 2000 11:07:01 -0500 Posted-Date: Wed, 22 Nov 2000 11:07:01 -0500 Message-Id: <5.0.1.4.2.20001122110012.00a78200@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 22 Nov 2000 11:02:36 -0500 To: "Ahmed Bhamjee" From: Russ Housley Subject: Re: S/MIME v3 implementations Cc: In-Reply-To: <000001c0546f$f170f9f0$c42078c1@sse.ie> References: <5.0.1.4.2.20001121100815.027ad180@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You need to take a closer look at RFC 2630 and RFC 2631. You might need to generate a different ephemeral key for each recipient. You can use the same one for multiple recipients if and only if they have the same p, q, and g domain parameter values. The originator must use the recipient domain parameters when generating the ephemeral key pair. Russ At 10:35 AM 11/22/2000 +0000, Ahmed Bhamjee wrote: >Could someone please provide me (or point me to a location where I can find) >a list of products which implement Diffie-Hellman as per RFC 2631. > >Also, when using Diffie-Hellman Ephemeral-Static mode, what key size do you >use to generate a new key pair. You could use the key size of the recipient, >but what if you are sending the same message to multiple recipients who may >have different DH key sizes. Another option is to use the size of your own >static DH key pair. > >I would appreciate any advice or help with this. > >Thanks in advance >Ahmed From owner-ietf-smime Wed Nov 22 08:38:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17017 for ietf-smime-bks; Wed, 22 Nov 2000 08:38:30 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17013 for ; Wed, 22 Nov 2000 08:38:28 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 11:38:55 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B18ED@wfhqex01.wangfed.com> From: "Pawling, John" To: "'Ahmed Bhamjee'" , ietf-smime@imc.org Subject: RE: S/MIME v3 implementations Date: Wed, 22 Nov 2000 11:38:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ahmed, The S/MIME Freeware Library (SFL) uses the freeware Crypto++ library to implement RFC 2631. We have performed successful RFC 2631 interoperability testing between the SFL and the Microsoft Outlook 2000 S/MIME v3 implementation. Also, the SFL has been used to perform RFC 2631 interoperability testing with Baltimore Technologies S/MIME v3 implementation. When using E-S D-H, the originator uses the recipient's D-H public key parameters to generate the originator's ephemeral D-H private/public key pair. If you are sending the same message to multiple recipients who have different D-H key sizes, then the originator can generate a unique ephemeral D-H private/public key pair for each different recipient key size. In this case, the originator would include a separate RecipientInfo in the EnvelopedData for each different recipient key size. Please let me know if you require further information regarding the SFL or the interoperability testing that we have conducted. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Ahmed Bhamjee [mailto:ahmed.bhamjee@sse.ie] Sent: Wednesday, November 22, 2000 5:36 AM To: ietf-smime@imc.org Subject: S/MIME v3 implementations Could someone please provide me (or point me to a location where I can find) a list of products which implement Diffie-Hellman as per RFC 2631. Also, when using Diffie-Hellman Ephemeral-Static mode, what key size do you use to generate a new key pair. You could use the key size of the recipient, but what if you are sending the same message to multiple recipients who may have different DH key sizes. Another option is to use the size of your own static DH key pair. I would appreciate any advice or help with this. Thanks in advance Ahmed From owner-ietf-smime Wed Nov 22 16:23:11 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07941 for ietf-smime-bks; Wed, 22 Nov 2000 16:23:11 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07930 for ; Wed, 22 Nov 2000 16:23:10 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (208-58-192-39.s39.tnt9.lnhva.md.dialup.rcn.com [208.58.192.39]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA09287 for ; Wed, 22 Nov 2000 16:23:33 -0800 (PST) Message-Id: <5.0.1.4.2.20001122190005.02742a70@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 22 Nov 2000 19:03:54 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Draft S/MIME WG Agenda for San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please contact me immediately if you would like a time slot and you are not on the attached draft agenda. Russ DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT S/MIME Mail Security WG Agenda San Diego, California December 2000 Introductions Russ Housley Working Group Status Russ Housley Interoperability Matrix Jim Schaad Security Policies and Labels (Weston Nicolls) Symmetric Key Distribution Sean Turner Domain Security (DOMSEC) Bill Ottaway Reuse of Content Encryption Keys Steve Farrell Advanced Encryption Standard (AES) Jim Schaad RSA as a MUST implement Blake Ramsdell S/MIME Freeware Library [*] John Pawling Wrap up Russ Housley ( ) Author cannot attend; proxy will lead discussion [*] If time permits From owner-ietf-smime Fri Nov 24 15:27:09 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA20117 for ietf-smime-bks; Fri, 24 Nov 2000 15:27:09 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20113 for ; Fri, 24 Nov 2000 15:27:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26403; Fri, 24 Nov 2000 18:28:12 -0500 (EST) Message-Id: <200011242328.SAA26403@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-domsec-07.txt Date: Fri, 24 Nov 2000 18:28:12 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Domain Security Services using S/MIME Author(s) : T. Dean, W. Ottaway Filename : draft-ietf-smime-domsec-07.txt Pages : 8 Date : 22-Nov-00 This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely, for example when two domains use incompatible messaging technologies such as X.400 series and SMTP/MIME, or when a single domain wishes to communicate securely with one of its members residing on an untrusted domain. The scenarios covered by this document are domain to domain, individual to domain and domain to individual communications. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-domsec-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-domsec-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001122150205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-domsec-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-domsec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Fri Nov 24 15:27:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20126 for ietf-smime-bks; Fri, 24 Nov 2000 15:27:12 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20121 for ; Fri, 24 Nov 2000 15:27:11 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26413; Fri, 24 Nov 2000 18:28:15 -0500 (EST) Message-Id: <200011242328.SAA26413@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-v31cert-00.txt Date: Fri, 24 Nov 2000 18:28:15 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Version 3.1 Certificate Profile Addendum Author(s) : B. Ramsdell Filename : draft-ietf-smime-v31cert-00.txt Pages : Date : 22-Nov-00 In light of the expiration of the primary RSA patent, it is proposed that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST implement algorithms in the S/MIME profile. This draft will describe only the proposed changes to the S/MIME Version 3 Certificate Handling RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-v31cert-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-v31cert-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-v31cert-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001122150214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-v31cert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-v31cert-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150214.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Fri Nov 24 15:27:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20132 for ietf-smime-bks; Fri, 24 Nov 2000 15:27:15 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20128 for ; Fri, 24 Nov 2000 15:27:13 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26425; Fri, 24 Nov 2000 18:28:18 -0500 (EST) Message-Id: <200011242328.SAA26425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-aes-alg-00.txt Date: Fri, 24 Nov 2000 18:28:18 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the Advanced Encryption Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-aes-alg-00.txt Pages : 6 Date : 22-Nov-00 This document specifies how to incorporate the Advanced Encryption Standard (AES) candidate algorithm [AES] into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that the AES algorithms may be included in the CMS specification [CMS] for symmetric content and key encryption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-aes-alg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-aes-alg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001122150223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-aes-alg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-aes-alg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150223.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Nov 27 11:10:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA24096 for ietf-smime-bks; Mon, 27 Nov 2000 11:10:15 -0800 (PST) Received: from public.szptt.net.cn (mail1-smtp.szptt.net.cn [202.96.136.221]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24090 for ; Mon, 27 Nov 2000 11:10:12 -0800 (PST) From: Internet-Drafts@ietf.org Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43a22e449; Mon, 27 Nov 2000 19:09:31 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm113a1f8958; Sat, 25 Nov 2000 05:07:48 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id XAA14999 for ietf-123-outbound.01@ietf.org; Fri, 24 Nov 2000 23:45:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id SAA12465 for ; Fri, 24 Nov 2000 18:28:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26413; Fri, 24 Nov 2000 18:28:15 -0500 (EST) Message-Id: <200011242328.SAA26413@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-v31cert-00.txt Date: Fri, 24 Nov 2000 18:28:15 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Version 3.1 Certificate Profile Addendum Author(s) : B. Ramsdell Filename : draft-ietf-smime-v31cert-00.txt Pages : Date : 22-Nov-00 In light of the expiration of the primary RSA patent, it is proposed that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST implement algorithms in the S/MIME profile. This draft will describe only the proposed changes to the S/MIME Version 3 Certificate Handling RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-v31cert-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-v31cert-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-v31cert-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001122150214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-v31cert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-v31cert-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150214.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Mon Nov 27 12:56:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA01479 for ietf-smime-bks; Mon, 27 Nov 2000 12:56:07 -0800 (PST) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01473 for ; Mon, 27 Nov 2000 12:56:05 -0800 (PST) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id PAA20766 for ; Mon, 27 Nov 2000 15:32:56 -0500 (EST) Message-Id: <200011272032.PAA20762@roadblock.missi.ncsc.mil> Date: Mon, 27 Nov 2000 15:49:24 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: I-D ACTION:draft-ietf-smime-v31cert-00.txt To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SqyP0BetNrZE6qqnZjCF7A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Title : S/MIME Version 3.1 Certificate Profile Addendum > Author(s) : B. Ramsdell > Filename : draft-ietf-smime-v31cert-00.txt > Pages : > Date : 22-Nov-00 > > In light of the expiration of the primary RSA patent, it is proposed > that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST > implement algorithms in the S/MIME profile. This draft will describe > only the proposed changes to the S/MIME Version 3 Certificate Handling > RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. Did I miss the discussion and consensus on this? I was under the impression that RSA does not replace DSA as a MUST-implement, rather RSA becomes an additional MUST for signatures: > Russ Housley on 07/31/2000 05:04:52 PM > > Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode The Certificate Profile should reflect the results of the last meeting and subsequent mail list discussion. From owner-ietf-smime Mon Nov 27 14:02:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04119 for ietf-smime-bks; Mon, 27 Nov 2000 14:02:26 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04115 for ; Mon, 27 Nov 2000 14:02:25 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA23359; Mon, 27 Nov 2000 14:03:13 -0800 (PST) Message-Id: <5.0.1.4.2.20001127164203.027c0e70@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 27 Nov 2000 16:46:08 -0500 To: "David P. Kemp" From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-v31cert-00.txt Cc: ietf-smime@imc.org In-Reply-To: <200011272032.PAA20762@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave: You did not miss anything. This is a proposed change. The Working Group has not agreed or rejected the proposal. Russ At 03:49 PM 11/27/2000 -0500, David P. Kemp wrote: > > Title : S/MIME Version 3.1 Certificate Profile Addendum > > Author(s) : B. Ramsdell > > Filename : draft-ietf-smime-v31cert-00.txt > > Pages : > > Date : 22-Nov-00 > > > > In light of the expiration of the primary RSA patent, it is proposed > > that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST > > implement algorithms in the S/MIME profile. This draft will describe > > only the proposed changes to the S/MIME Version 3 Certificate Handling > > RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. > > >Did I miss the discussion and consensus on this? > >I was under the impression that RSA does not replace DSA as a >MUST-implement, rather RSA becomes an additional MUST for signatures: > > > > Russ Housley on 07/31/2000 05:04:52 PM > > > > Proposed way forward: Change the mandatory to implement algorithm set to: > > One-way Hash: SHA-1 (no change) > > Signature: Both DSA and RSA (PKCS#1 v1.5) > > Key Mgmt: RSA (OAEP) > > Eencryption: Triple-DES in CBC mode > > >The Certificate Profile should reflect the results of the last meeting >and subsequent mail list discussion. From owner-ietf-smime Mon Nov 27 14:01:23 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04067 for ietf-smime-bks; Mon, 27 Nov 2000 14:01:23 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA04063 for ; Mon, 27 Nov 2000 14:01:21 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Mon, 27 Nov 2000 14:02:13 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 14:02:13 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C5A77582@mail.deming.com> From: "Blake Ramsdell" To: "'David P. Kemp'" , ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-v31cert-00.txt Date: Mon, 27 Nov 2000 14:02:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 163C066F27524-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree, and I screwed up. Basically I just took the -ramsdell draft and made it -smime, and I forgot to change the language. The msg draft didn't get submitted, as I submitted the -ramsdell version instead of the -smime version. I think the wording is fixed in there, and you can certainly point out anything that I missed. I will send it to the list soon. Blake -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Monday, November 27, 2000 12:49 PM To: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-v31cert-00.txt > Title : S/MIME Version 3.1 Certificate Profile Addendum > Author(s) : B. Ramsdell > Filename : draft-ietf-smime-v31cert-00.txt > Pages : > Date : 22-Nov-00 > > In light of the expiration of the primary RSA patent, it is proposed > that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST > implement algorithms in the S/MIME profile. This draft will describe > only the proposed changes to the S/MIME Version 3 Certificate Handling > RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. Did I miss the discussion and consensus on this? I was under the impression that RSA does not replace DSA as a MUST-implement, rather RSA becomes an additional MUST for signatures: > Russ Housley on 07/31/2000 05:04:52 PM > > Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode The Certificate Profile should reflect the results of the last meeting and subsequent mail list discussion. From owner-ietf-smime Mon Nov 27 15:03:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA06564 for ietf-smime-bks; Mon, 27 Nov 2000 15:03:33 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA06556 for ; Mon, 27 Nov 2000 15:03:31 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Nov 2000 16:04:20 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 27 Nov 2000 16:04:16 -0700 From: "Bob Jueneman" To: , Subject: RSA vs. DSA MUST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA06557 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, is the issue whether RSA should REPLACE DSA as a MUST, as opposed to merely adding an additional MUST for RSA for signatures? I doubt that there would be any strong disagreement about adding RSA as a MUST, since it has been a commercial requirement and de facto standard all along, regardless of IETF politics. But other than the patent issues, is there still a strong technical, marketing or other consensus in favor of continuing DSA as a MUST? To date, we haven't implemented DSA in GroupWise, nor in the Novell Cert. Server, due to the complete absence of customer demand. In fact, when we looked around, we couldn't find any certificates that used DSA (granted, we probably didn't look very hard.) Do any of the US DoD PKI or e-mail initiatives have any serious plans to MANDATE the exclusive use of DSA? Does anyone else care strongly? Regards, Bob Robert R. Jueneman Security Architect Novell, Inc -- the leading provider of Net services software >>> "David P. Kemp" 11/27/00 01:49PM >>> > Title : S/MIME Version 3.1 Certificate Profile Addendum > Author(s) : B. Ramsdell > Filename : draft-ietf-smime-v31cert-00.txt > Pages : > Date : 22-Nov-00 > > In light of the expiration of the primary RSA patent, it is proposed > that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST > implement algorithms in the S/MIME profile. This draft will describe > only the proposed changes to the S/MIME Version 3 Certificate Handling > RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. Did I miss the discussion and consensus on this? I was under the impression that RSA does not replace DSA as a MUST-implement, rather RSA becomes an additional MUST for signatures: > Russ Housley on 07/31/2000 05:04:52 PM > > Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode The Certificate Profile should reflect the results of the last meeting and subsequent mail list discussion. From owner-ietf-smime Mon Nov 27 16:50:46 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA08126 for ietf-smime-bks; Mon, 27 Nov 2000 16:50:46 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08122 for ; Mon, 27 Nov 2000 16:50:45 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Mon, 27 Nov 2000 16:51:38 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 16:51:37 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C5A77587@mail.deming.com> From: "Blake Ramsdell" To: "'Bob Jueneman'" , ietf-smime@imc.org, dpkemp@missi.ncsc.mil Subject: RE: RSA vs. DSA MUST Date: Mon, 27 Nov 2000 16:51:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 163DDE1028396-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I do not care strongly, but the strawpoll at the last IETF indicated a preference for "both", and that was the path we were headed down, and that Russ summarized. Personally, I don't implement it, and I haven't had any customer complaints telling me I should, and the backwards compatibility issues are almost the same as for Diffie-Hellman certs (that is, I have not seen anyone using them, so chucking them wouldn't break an installed base of significant size, if at all). Blake -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Monday, November 27, 2000 3:04 PM To: ietf-smime@imc.org; dpkemp@missi.ncsc.mil Subject: RSA vs. DSA MUST David, is the issue whether RSA should REPLACE DSA as a MUST, as opposed to merely adding an additional MUST for RSA for signatures? I doubt that there would be any strong disagreement about adding RSA as a MUST, since it has been a commercial requirement and de facto standard all along, regardless of IETF politics. But other than the patent issues, is there still a strong technical, marketing or other consensus in favor of continuing DSA as a MUST? To date, we haven't implemented DSA in GroupWise, nor in the Novell Cert. Server, due to the complete absence of customer demand. In fact, when we looked around, we couldn't find any certificates that used DSA (granted, we probably didn't look very hard.) Do any of the US DoD PKI or e-mail initiatives have any serious plans to MANDATE the exclusive use of DSA? Does anyone else care strongly? Regards, Bob Robert R. Jueneman Security Architect Novell, Inc -- the leading provider of Net services software >>> "David P. Kemp" 11/27/00 01:49PM >>> > Title : S/MIME Version 3.1 Certificate Profile Addendum > Author(s) : B. Ramsdell > Filename : draft-ietf-smime-v31cert-00.txt > Pages : > Date : 22-Nov-00 > > In light of the expiration of the primary RSA patent, it is proposed > that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST > implement algorithms in the S/MIME profile. This draft will describe > only the proposed changes to the S/MIME Version 3 Certificate Handling > RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. Did I miss the discussion and consensus on this? I was under the impression that RSA does not replace DSA as a MUST-implement, rather RSA becomes an additional MUST for signatures: > Russ Housley on 07/31/2000 05:04:52 PM > > Proposed way forward: Change the mandatory to implement algorithm set to: > One-way Hash: SHA-1 (no change) > Signature: Both DSA and RSA (PKCS#1 v1.5) > Key Mgmt: RSA (OAEP) > Eencryption: Triple-DES in CBC mode The Certificate Profile should reflect the results of the last meeting and subsequent mail list discussion. From owner-ietf-smime Mon Nov 27 17:21:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA08629 for ietf-smime-bks; Mon, 27 Nov 2000 17:21:41 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08621 for ; Mon, 27 Nov 2000 17:21:30 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA10456; Tue, 28 Nov 2000 14:10:44 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97537385624891>; Tue, 28 Nov 2000 14:10:56 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: bjueneman@novell.com, blake.ramsdell@tumbleweed.com, dpkemp@missi.ncsc.mil, ietf-smime@imc.org Subject: RE: RSA vs. DSA MUST Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Tue, 28 Nov 2000 14:10:56 (NZDT) Message-ID: <97537385624891@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >I do not care strongly, but the strawpoll at the last IETF indicated a >preference for "both", and that was the path we were headed down, and that >Russ summarized. Personally, I don't implement it, and I haven't had any >customer complaints telling me I should, and the backwards compatibility >issues are almost the same as for Diffie-Hellman certs (that is, I have not >seen anyone using them, so chucking them wouldn't break an installed base of >significant size, if at all). In case this is useful as a data point, in my general wandering around looking for certs on the net the only publicly available DSA certs I've ever found were some old Thawte ones, presumably created just to show'em (all the standard Thawte certs are RSA, I don't think I've ever seen the DSA certs actually used to certify anything). I've also very occasionally come across them being used in closed environments (ie ones where interoperability with the masses isn't really an issue). I suspect the motivation for a lot of these is that there's a requirement to use a FIPS algorithm and DSA is the only choice. I can't see a MUST RSA, MAY DSA as being any real problem, it's just recognising what has been reality for the last few years. Peter. From owner-ietf-smime Mon Nov 27 18:54:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10224 for ietf-smime-bks; Mon, 27 Nov 2000 18:54:59 -0800 (PST) Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA10220 for ; Mon, 27 Nov 2000 18:54:56 -0800 (PST) Received: (qmail 10681 invoked from network); 28 Nov 2000 02:55:42 -0000 Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 28 Nov 2000 02:55:42 -0000 Message-ID: <007a01c058e6$a5ccf910$6000a8c0@em> From: "Enzo Michelangeli" To: , References: <97537385624891@kahu.cs.auckland.ac.nz> Subject: Re: RSA vs. DSA MUST Date: Tue, 28 Nov 2000 10:54:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; Sent: Tuesday, November 28, 2000 2:10 PM Subject: RE: RSA vs. DSA MUST > In case this is useful as a data point, in my general wandering around looking > for certs on the net the only publicly available DSA certs I've ever found were > some old Thawte ones, presumably created just to show'em (all the standard > Thawte certs are RSA, I don't think I've ever seen the DSA certs actually used > to certify anything). I've also very occasionally come across them being used > in closed environments (ie ones where interoperability with the masses isn't > really an issue). I suspect the motivation for a lot of these is that there's > a requirement to use a FIPS algorithm and DSA is the only choice. I can't see > a MUST RSA, MAY DSA as being any real problem, it's just recognising what has > been reality for the last few years. Well, there is one problem, and it's due to the store-and-forwad nature of e-mail which prevents negotiation, making it impossible to know whether a given algorithm is supported by a new recipient (think, e.g., of signed messages sent to mailing list). The result is that everybody ends up using ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this was precisely the root of the trouble with 40-bit security in the bad old days: a sort of Grisham's Law for algorithms... In my opinion, "MAY" algorithms are pretty useless in non-interactive contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might as well be dropped altogether. Enzo From owner-ietf-smime Tue Nov 28 07:20:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04685 for ietf-smime-bks; Tue, 28 Nov 2000 07:20:15 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA04681 for ; Tue, 28 Nov 2000 07:20:13 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 08:20:49 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 28 Nov 2000 08:20:42 -0700 From: "Bob Jueneman" To: , , , Subject: RE: RSA vs. DSA MUST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA04682 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >"Blake Ramsdell" writes: > >>I do not care strongly, but the strawpoll at the last IETF indicated a >>preference for "both", and that was the path we were headed down, and that >>Russ summarized. Personally, I don't implement it, and I haven't had any >>customer complaints telling me I should, and the backwards compatibility >>issues are almost the same as for Diffie-Hellman certs (that is, I have not >>seen anyone using them, so chucking them wouldn't break an installed base of >>significant size, if at all). > >In case this is useful as a data point, in my general wandering around looking >for certs on the net the only publicly available DSA certs I've ever found were >some old Thawte ones, presumably created just to show'em (all the standard >Thawte certs are RSA, I don't think I've ever seen the DSA certs actually used >to certify anything). I've also very occasionally come across them being used >in closed environments (ie ones where interoperability with the masses isn't >really an issue). I suspect the motivation for a lot of these is that there's >a requirement to use a FIPS algorithm and DSA is the only choice. I can't see >a MUST RSA, MAY DSA as being any real problem, it's just recognising what has >been reality for the last few years. > >Peter. > That would certainly be my preference, unless some hitherto-unknown set of customers waving gobs of money come running out of the woods. Even MAY language is somewhat troubling -- I continue to believe that the SMIME group has gotten seriously off track by introducing orphan algorithms such as CAST, IDEA, symmetric key, password-encryption, etc., etc., that if implemented would add only incrementally to the coding effort, but would complicate interoperability testing exponentially. I wouldn't object to MAY for DSA, but I would strongly prefer that it not be a MUST. If DSA is a MUST, then I strongly suspect that we and probably many other vendors will simply be noncompliant, and that doesn't help anyone, especially with respect to interoperability. And isn't that what standards are all about? Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software From owner-ietf-smime Tue Nov 28 08:07:52 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA11760 for ietf-smime-bks; Tue, 28 Nov 2000 08:07:52 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11756 for ; Tue, 28 Nov 2000 08:07:51 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id eASG0lD04598 for ; Tue, 28 Nov 2000 08:00:52 -0800 (PST) Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G4QSUH00.DFT; Tue, 28 Nov 2000 08:08:41 -0800 Message-ID: <3A23D889.1000501@netscape.com> Date: Tue, 28 Nov 2000 08:08:41 -0800 From: relyea@netscape.com (Bob Relyea) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Enzo Michelangeli CC: pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: <97537385624891@kahu.cs.auckland.ac.nz> <007a01c058e6$a5ccf910$6000a8c0@em> Content-Type: multipart/alternative; boundary="------------040104030509030409020307" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040104030509030409020307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Enzo Michelangeli wrote: > really an issue). I suspect the motivation for a lot of these is that > > there's > >> a requirement to use a FIPS algorithm and DSA is the only choice. I can't > > see > >> a MUST RSA, MAY DSA as being any real problem, it's just recognising what > > has > >> been reality for the last few years. > We have seen a lot of DSA certificates generated by the U.S. Government. What we haven't seen is a lot of DH certificates (The government uses KEA, which is a form of DH that uses two DH keys and then skipjack to do some key mixing). > Well, there is one problem, and it's due to the store-and-forwad nature of > e-mail which prevents negotiation, making it impossible to know whether a > given algorithm is supported by a new recipient (think, e.g., of signed > messages sent to mailing list). It's even worse for asymetric algorithms. Even if you had information to allow a negotiated symetric cipher, you are stuck with the asymetric cipher based on the user's certificate. If we were talking DH, I'd say there isn't much point, but I've seen a lot of DSA stuff running around, and suspect, because of FIPs, to see more of it. I'd vote to make it MUST. bob > --------------040104030509030409020307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Enzo Michelangeli wrote:
really an issue).  I suspect the motivation for a lot of these is that
there's
a requirement to use a FIPS algorithm and DSA is the only choice.  I can't
see
a MUST RSA, MAY DSA as being any real problem, it's just recognising what
has
been reality for the last few years.

We have seen a lot of DSA certificates generated by the U.S. Government. What we haven't seen is a lot of DH certificates (The government uses KEA, which is a form of DH that uses two DH keys and then skipjack to do some key mixing).

Well, there is one problem, and it's due to the store-and-forwad nature of
e-mail which prevents negotiation, making it impossible to know whether a
given algorithm is supported by a new recipient (think, e.g., of signed
messages sent to mailing list).
It's even worse for asymetric algorithms. Even if you had information to allow a negotiated symetric cipher, you are stuck with the asymetric cipher based on the user's certificate.

If we were talking DH, I'd say there isn't much point, but I've seen a lot of DSA stuff running around, and suspect, because of FIPs, to see more of it. I'd vote to make it MUST.


bob



--------------040104030509030409020307-- From owner-ietf-smime Tue Nov 28 09:06:38 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA21662 for ietf-smime-bks; Tue, 28 Nov 2000 09:06:38 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA21653 for ; Tue, 28 Nov 2000 09:06:35 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 10:07:17 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 28 Nov 2000 10:07:17 -0700 From: "Tolga Acar" To: Subject: Re: RSA vs. DSA MUST Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_C299D655.CBAAC9F1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_C299D655.CBAAC9F1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > In case this is useful as a data point, in my general wandering around = looking > for certs on the net the only publicly available DSA certs I've ever = found were > some old Thawte ones, presumably created just to show'em (all the = standard > Thawte certs are RSA, I don't think I've ever seen the DSA certs = actually used > to certify anything). I've also very occasionally come across them = being used > in closed environments (ie ones where interoperability with the masses = isn't > really an issue). I suspect the motivation for a lot of these is that = there's > a requirement to use a FIPS algorithm and DSA is the only choice. I = can't see > a MUST RSA, MAY DSA as being any real problem, it's just recognising = what has > been reality for the last few years. DSA is not the ONLY asymmetric algorithm certifiable in FIPS 140-1/2, as = it references any algorithm published/referenced in a FIPS; X9.31 and = X9.62 are also specified in FIPS 186-2. Remember that DSS it not DSA. Looking forward (that's what this is about, isn't it?), there are three = asymmetric algorithms in FIPS 68-2: DSA, X9.31 RSA, and X9.62 ECDSA. So, the motivation for a lot of those certificates based on FIPS 186-1 and = FIPS 140-1, is not there anymore. It is enough to support one of them for FIPS purposes, then the most = common one, RSA, should do fine. NIST certainly does not mandate all of = them (FIPS 186-2, page 3, line 3). Effective as of July 27, 2000, and with the prescribed transition period = of FIPS 186-2 from July 27 2000 to July 27 2001, that should give enough = time to make changes in a product line. - Tolga --=_C299D655.CBAAC9F1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> In case this is useful as a data point, in my general = wandering=20 around looking
> for certs on the net the only publicly available = DSA=20 certs I've ever found were
> some old Thawte ones, presumably = created just=20 to show'em (all the standard
> Thawte certs are RSA, I don't think = I've=20 ever seen the DSA certs actually used
> to certify anything).  = I've=20 also very occasionally come across them being used
> in closed=20 environments (ie ones where interoperability with the masses isn't
>= =20 really an issue).  I suspect the motivation for a lot of these is = that=20 there's
> a requirement to use a FIPS algorithm and DSA is the = only=20 choice.  I can't see
> a MUST RSA, MAY DSA as being any real = problem,=20 it's just recognising what has
> been reality for the last few=20 years.

DSA is not the ONLY asymmetric algorithm certifiable in = FIPS=20 140-1/2, as it references any algorithm published/referenced in a = FIPS; =20 X9.31 and X9.62 are also specified in FIPS 186-2.
Remember that DSS it not DSA.
Looking forward (that's what this is about, isn't it?), there are = three=20 asymmetric algorithms in FIPS 68-2: DSA, X9.31 RSA, and X9.62 ECDSA.
So, the motivation for a lot of those certificates based on FIPS = 186-1 and=20 FIPS 140-1, is not there anymore.
It is enough to support one of them for FIPS purposes, then the most = common=20 one, RSA, should do fine. NIST certainly does not mandate all of them = (FIPS=20 186-2, page 3, line 3).
Effective as of July 27, 2000, and with the prescribed transition = period of=20 FIPS 186-2 from July 27 2000 to July 27 2001, that should give enough time = to=20 make changes in a product line.
 
- Tolga
--=_C299D655.CBAAC9F1-- From owner-ietf-smime Tue Nov 28 09:21:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23487 for ietf-smime-bks; Tue, 28 Nov 2000 09:21:48 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23482 for ; Tue, 28 Nov 2000 09:21:47 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 10:22:40 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 28 Nov 2000 10:22:36 -0700 From: "Bob Jueneman" To: , , Subject: Re: RSA vs. DSA MUST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23484 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Well, there is one problem, and it's due to the store-and-forward nature of >e-mail which prevents negotiation, making it impossible to know whether a >given algorithm is supported by a new recipient (think, e.g., of signed >messages sent to mailing list). The result is that everybody ends up using >ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this >was precisely the root of the trouble with 40-bit security in the bad old >days: a sort of Gresham's Law for algorithms... >In my opinion, "MAY" algorithms are pretty useless in non-interactive >contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might >as well be dropped altogether. > >Enzo > Although it isn't strictly interactive in the sense that SSL is, the SMIMECapabilities attribute allows the originator of a message to indicate his preference as to encryption algorithms, including 40-bit RC4 vs. 56-bit DES vs. 128-bit whatever vs. 196-bit triple-DES (and soon, presumably, 256-bit AES). (Granted, some implementations ignore the attribute and default to the lowest common denominator (boo, hiss), and others use whatever algorithm and key size the originator selects, regardless of what the recipient specified.) I don't have the text in front of me, but isn't it possible to indicate the preferred key exchange and signature algorithms (and hashing algorithms, in order to handle SHA-384 and SHA-512) in the same manner? If not, it probably ought to be amended. Bob From owner-ietf-smime Tue Nov 28 09:30:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24139 for ietf-smime-bks; Tue, 28 Nov 2000 09:30:02 -0800 (PST) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24127 for ; Tue, 28 Nov 2000 09:30:00 -0800 (PST) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA01789 for ; Tue, 28 Nov 2000 12:06:49 -0500 (EST) Message-Id: <200011281706.MAA01780@roadblock.missi.ncsc.mil> Date: Tue, 28 Nov 2000 12:23:21 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: RSA vs. DSA MUST To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: s/58JT4eiiBmy3uAQ4fStA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Enzo has captured the chicken-and-egg essence of my concern. The U.S. Government has a requirement to purchase products which support FIPS 186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1 RSA). And, at least in the DoD, we have requirements coming from our customers to be algorithm independent: "PKI must support a variety of public key cryptographic algorithms both in the public/private key pairs created and certified by PKI, and in the algorithms used to apply digital signatures to certificates and other PKI products. PKI must support the concurrent use of several digital signature algorithms for issuing certificates and must be able to migrate over time to using new signature algorithms." -- DoD PKI Operational Requirements Document, 22 October 2000 There is also the fact that DSA signatures are significantly smaller than RSA signatures, especially as we move to public keys above 1024 bits and the signature could be bigger than the entire to-be-signed certificate. This doesn't matter in many environments, but it does in some. If vendors look at what certificates have already been issued to decide what certificates to support in products under development, we will never evolve. I favor keeping DSA (in addition to RSA) as a MUST for S/MIME clients because algorithm independence is valuable in and of itself. Dave > From: "Enzo Michelangeli" > > Well, there is one problem, and it's due to the store-and-forwad nature of > e-mail which prevents negotiation, making it impossible to know whether a > given algorithm is supported by a new recipient (think, e.g., of signed > messages sent to mailing list). The result is that everybody ends up using > ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this > was precisely the root of the trouble with 40-bit security in the bad old > days: a sort of Grisham's Law for algorithms... > In my opinion, "MAY" algorithms are pretty useless in non-interactive > contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might > as well be dropped altogether. > > Enzo From owner-ietf-smime Tue Nov 28 11:17:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA02921 for ietf-smime-bks; Tue, 28 Nov 2000 11:17:49 -0800 (PST) Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02916 for ; Tue, 28 Nov 2000 11:17:48 -0800 (PST) Received: from D00425 ([206.222.76.33]) by luc.ab.org (Netscape Messaging Server 3.6) with SMTP id AAA95CD1 for ; Tue, 28 Nov 2000 14:25:03 -0500 From: "Ozan Gonenc" To: Subject: RE: RSA vs. DSA MUST Date: Tue, 28 Nov 2000 14:17:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there a study readily available comparing all these FIPS-140 approved algorithms in question? I'm sure each one of them have there unique advantages and disadvantages (i.e. processing speeds, cryptanalysis). Limiting ourselves to only one algorithm to lessen coding efforts and simplifying interoperability may be detrimental as new attack methods evolve day-to-day. Yes customer-demands is what drives vendor development but what do you think the customer will demand if a serious RSA vulnerability is identified when new cryptanalysis technologies become available? Even as a rumor or a hoax (i.e. unproven/unofficial RSA crack), customers' demand will be mail packages with multi-algorithm capability. A mail agent's capability to use a variety of algorithms is a major selling point. I know this may be a little far-fetched but we should keep standards as accomodating as possible for any future possiblities. Maybe the limiting factor should be FIPS approved algorithms... Regards, Ozan ______________________________ Ozan Gonenc IT Security Consultant AEPOS Technologies Corporation -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Bob Jueneman Sent: November 28, 2000 10:21 To: pgut001@cs.aucKland.ac.nz; ietf-smime@imc.org; dpkemp@missi.ncsc.mil; blake.ramsdell@tumbleweed.com Subject: RE: RSA vs. DSA MUST >"Blake Ramsdell" writes: > >>I do not care strongly, but the strawpoll at the last IETF indicated a >>preference for "both", and that was the path we were headed down, and that >>Russ summarized. Personally, I don't implement it, and I haven't had any >>customer complaints telling me I should, and the backwards compatibility >>issues are almost the same as for Diffie-Hellman certs (that is, I have not >>seen anyone using them, so chucking them wouldn't break an installed base of >>significant size, if at all). > >In case this is useful as a data point, in my general wandering around looking >for certs on the net the only publicly available DSA certs I've ever found were >some old Thawte ones, presumably created just to show'em (all the standard >Thawte certs are RSA, I don't think I've ever seen the DSA certs actually used >to certify anything). I've also very occasionally come across them being used >in closed environments (ie ones where interoperability with the masses isn't >really an issue). I suspect the motivation for a lot of these is that there's >a requirement to use a FIPS algorithm and DSA is the only choice. I can't see >a MUST RSA, MAY DSA as being any real problem, it's just recognising what has >been reality for the last few years. > >Peter. > That would certainly be my preference, unless some hitherto-unknown set of customers waving gobs of money come running out of the woods. Even MAY language is somewhat troubling -- I continue to believe that the SMIME group has gotten seriously off track by introducing orphan algorithms such as CAST, IDEA, symmetric key, password-encryption, etc., etc., that if implemented would add only incrementally to the coding effort, but would complicate interoperability testing exponentially. I wouldn't object to MAY for DSA, but I would strongly prefer that it not be a MUST. If DSA is a MUST, then I strongly suspect that we and probably many other vendors will simply be noncompliant, and that doesn't help anyone, especially with respect to interoperability. And isn't that what standards are all about? Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software From owner-ietf-smime Tue Nov 28 11:47:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05633 for ietf-smime-bks; Tue, 28 Nov 2000 11:47:08 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05628 for ; Tue, 28 Nov 2000 11:47:06 -0800 (PST) Received: from [192.168.1.35] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G4R00CLN22DRZ@mta5.snfc21.pbi.net> for ietf-smime@imc.org; Tue, 28 Nov 2000 11:27:50 -0800 (PST) Date: Tue, 28 Nov 2000 11:29:23 -0800 From: Aram Perez Subject: Re: RSA vs. DSA MUST In-reply-to: <200011281706.MAA01780@roadblock.missi.ncsc.mil> To: ietf-smime@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David Kemp wrote: [snip] > If vendors look at what certificates have already been issued to decide > what certificates to support in products under development, we will never > evolve. I favor keeping DSA (in addition to RSA) as a MUST for S/MIME > clients because algorithm independence is valuable in and of itself. Was S/MIME not algorithm independent when DSA was a MUST? How would substituting DSA with RSA change the independence? DOD could mandate S/MIME with DSA even if S/MIME requires RSA. Someone could write a S/MIME with DSA document similar to the ones with IDEA, CAST, etc. Regards, Aram Perez From owner-ietf-smime Tue Nov 28 15:33:10 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA17027 for ietf-smime-bks; Tue, 28 Nov 2000 15:33:10 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17020 for ; Tue, 28 Nov 2000 15:33:08 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Nov 2000 16:33:57 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 28 Nov 2000 16:33:50 -0700 From: "Bob Jueneman" To: , Subject: Re: RSA vs. DSA MUST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA17021 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chicken and egg is exactly the situation we find ourselves in. Implementors certainly want to support their customers, but don't want to be "required" by standards to implement algorithms that no one uses or are willing to pay for. Ozan Gonenc also makes a good point in suggesting that perhaps the MUST algorithms be limited to FIPS approved algorithms. I'm a slightly concerned that this may be too US-centric a view, but on the other hand I haven't heard of any other governments or customers requiring or promoting any other algorithms, except for unpublished/proprietary/classified algorithms used in certain restricted sectors. (An exception might be GOST, but so far we can't even get the Russians to agree to pay anything for the capability., much less anyone else) So maybe limiting the MUST algorithms to a subset of the FIPS-approved list is acceptable. At least the FIPS listing implies a rather serious degree of vetting as to the security of the algorithms, which is something I don't think the IETF is institutionally capable of, not withstanding the cryptographic expertise of some of the members. The point about having at least one algorithm in the suite that could be used if RSA were suddenly shown to be seriously flawed is also valid, so long as we don't get carried away with the list! FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic Curve DSA; but not PKCS-1 RSA, the one interoperable algorithm that everyone is using presently! Hmm. I'm not necessarily advocating this position -- I might like to think about it some more myself -- but just for the sake of argument and to take the pulse, what would people think of making ANSI X9.31 RSA a MUST, X9.31 EC-DSA a SHOULD, and DSA and PKCS-1 RSA a MAY? It is my understanding that X9.31 RSA is considered to be superior to PKCS-1 RSA in terms of resistance to certain forms of attack, and should not be that great a stretch for existing RSA implementations, and hence the MUST. We wouldn't deprecate PKCS-1 RSA (at least not yet), since it must continue to be supported for backwards compatibility. This wouldn't deprecate DSA either, but it wouldn't be required for people outside of the (quite limited) community of interest presently using it. EC-DSA certainly beats regular DSA in terms of speed and size and deserves to be included in its own right, but I'm not entirely clear as to the patent situation, hence the SHOULD and not a MUST. In the area of symmetric algorithms, as soon as Rijndael is officially certified as the AES algorithm I believe we should promote AES to MUST, along with triple-DES and single DES for backwards compatibility. ( haven't heard of anyone clamoring for SKIPJACK, so I think it can safely be ignored in favor of triple-DES and/or AES.) Likewise, I think we will have to add SHA-386 and SHA-512 as MUST algorithms, along with SHA-1, and probably deprecate MD2 and MD5. What think ye? Bob >Enzo has captured the chicken-and-egg essence of my concern. The U.S. >Government has a requirement to purchase products which support FIPS >186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1 >RSA). And, at least in the DoD, we have requirements coming from our >customers to be algorithm independent: > > "PKI must support a variety of public key cryptographic algorithms > both in the public/private key pairs created and certified by PKI, > and in the algorithms used to apply digital signatures to certificates > and other PKI products. PKI must support the concurrent use of several > digital signature algorithms for issuing certificates and must be able > to migrate over time to using new signature algorithms." > > -- DoD PKI Operational Requirements Document, 22 October 2000 > > >There is also the fact that DSA signatures are significantly smaller >than RSA signatures, especially as we move to public keys above 1024 bits >and the signature could be bigger than the entire to-be-signed certificate. >This doesn't matter in many environments, but it does in some. > >If vendors look at what certificates have already been issued to decide >what certificates to support in products under development, we will never >evolve. I favor keeping DSA (in addition to RSA) as a MUST for S/MIME >clients because algorithm independence is valuable in and of itself. > >Dave > > > >> From: "Enzo Michelangeli" >> >> Well, there is one problem, and it's due to the store-and-forwad nature of >> e-mail which prevents negotiation, making it impossible to know whether a >> given algorithm is supported by a new recipient (think, e.g., of signed >> messages sent to mailing list). The result is that everybody ends up using >> ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this >> was precisely the root of the trouble with 40-bit security in the bad old >> days: a sort of Grisham's Law for algorithms... >> In my opinion, "MAY" algorithms are pretty useless in non-interactive >> contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might >> as well be dropped altogether. >> >> Enzo > From owner-ietf-smime Tue Nov 28 17:39:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20649 for ietf-smime-bks; Tue, 28 Nov 2000 17:39:27 -0800 (PST) Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA20645 for ; Tue, 28 Nov 2000 17:39:25 -0800 (PST) Received: (qmail 18123 invoked from network); 29 Nov 2000 01:40:50 -0000 Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 29 Nov 2000 01:40:50 -0000 Message-ID: <009101c059a5$5ba32bb0$6000a8c0@em> From: "Enzo Michelangeli" To: "Bob Jueneman" , , References: Subject: Re: RSA vs. DSA MUST Date: Wed, 29 Nov 2000 09:39:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Original Message ----- From: "Bob Jueneman" To: ; ; Sent: Wednesday, November 29, 2000 1:22 AM Subject: Re: RSA vs. DSA MUST > Although it isn't strictly interactive in the sense that SSL is, > the SMIMECapabilities attribute allows the originator of a message > to indicate his preference as to encryption algorithms, including > 40-bit RC4 vs. 56-bit DES > vs. 128-bit whatever vs. 196-bit > triple-DES (and soon, presumably, 256-bit AES). Yes, but on the open Internet most certificates are sent as part of the message (presently in PKCS#7 format), not retrieved from global directories as the X.500 folks initially hoped. In that context, the recipient would have to send an initial signed message to the sender to indicate the user agent's capabilities: and in most cases (like one I mentioned of the mailing list) that's just not viable. Enzo From owner-ietf-smime Tue Nov 28 17:43:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20720 for ietf-smime-bks; Tue, 28 Nov 2000 17:43:08 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20714 for ; Tue, 28 Nov 2000 17:43:03 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA06946; Wed, 29 Nov 2000 14:43:45 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97546223703233>; Wed, 29 Nov 2000 14:43:57 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: bjueneman@novell.com, dpkemp@missi.ncsc.mil, ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Wed, 29 Nov 2000 14:43:57 (NZDT) Message-ID: <97546223703233@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bob Jueneman" writes: >I'm not necessarily advocating this position -- I might like to think about it >some more myself -- but just for the sake of argument and to take the pulse, >what would people think of making ANSI X9.31 RSA a MUST, X9.31 EC-DSA a >SHOULD, and DSA and PKCS-1 RSA a MAY? How about trying to make the spec at least vaguely approximate reality in the choice of algorithms? It doesn't really matter if you include requirements like "MUST DSA OR WE WILL KILL YOU[0], SHOULD NOT RSA", in practice the world will interpret it as "MUST RSA, MAY DSA, SHOULD NOT X9.42 DH, BWAHAHAHAHAHA X9.31 RSA" no matter what it says in the RFC (I think IBM does X9.31 in CCA but does anything else in existence implement this?). I've been sitting here watching this debate go on and on, but since no matter what you put in the RFC the market will interpret it as MUST RSA and various levels of deprecation for anything else maybe we could get Markov Chaney to continue the debate for a while just for forms sake and then after enough messages have been exchanged to satisfy everyone either put text in the RFC which accepts what everyone's going to do anyway or which specifies all sorts of options and alternatives secure in the knowledge that implementors will ignore it and do what the market wants/expects, which ain't DSA or X9.31 RSA. Peter. [0] RFC 2026bis, "When MUST just isn't enough". From owner-ietf-smime Tue Nov 28 17:10:55 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA20065 for ietf-smime-bks; Tue, 28 Nov 2000 17:10:55 -0800 (PST) Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA20061 for ; Tue, 28 Nov 2000 17:10:52 -0800 (PST) Received: (qmail 8735 invoked from network); 29 Nov 2000 01:12:16 -0000 Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 29 Nov 2000 01:12:16 -0000 Message-ID: <004d01c059a1$5e0904f0$6000a8c0@em> From: "Enzo Michelangeli" To: "Bob Jueneman" , , References: Subject: Re: RSA vs. DSA MUST Date: Wed, 29 Nov 2000 09:11:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Considering that the patents issues with RSA have gone away, and that RSA Security in the past has been willing to grant royalty-free RC2 licenses for S/MIME products, is there any remaining reason for not requiring complete S/MIME v.2 backward compatibility as a MUST? If there aren't, I would add to the MUST list at least D-H, DSA and 3DES, just to prevent a global shutdown of secure e-mail if tomorrow someone finds flaws in one of the v.2 algorithms. I don't think that implementing some additional well understood and royalty-free algorithm would represent such a large cost to the industry, especially considering the wide availability of OpenSource libraries, licensed under BSD license or even more liberal terms, that can be used as a building block. Enzo ----- Original Message ----- From: "Bob Jueneman" To: ; Sent: Wednesday, November 29, 2000 7:33 AM Subject: Re: RSA vs. DSA MUST > Chicken and egg is exactly the situation we find ourselves in. Implementors certainly want to support their customers, but don't want to be "required" by standards to implement algorithms that no one uses or are willing to pay for. > > Ozan Gonenc also makes a good point in suggesting that perhaps the MUST algorithms be limited to FIPS approved algorithms. I'm a slightly concerned that this may be too US-centric a view, but on the other hand I haven't heard of any other governments or customers requiring or promoting any other algorithms, except for unpublished/proprietary/classified algorithms used in certain restricted sectors. (An exception might be GOST, but so far we can't even get the Russians to agree to pay anything for the capability., much less anyone else) So maybe limiting the MUST algorithms to a subset of the FIPS-approved list is acceptable. At least the FIPS listing implies a rather serious degree of vetting as to the security of the algorithms, which is something I don't think the IETF is institutionally capable of, not withstanding the cryptographic expertise of some of the members. > > The point about having at least one algorithm in the suite that could be used if RSA were suddenly shown to be seriously flawed is also valid, so long as we don't get carried away with the list! > > FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic Curve DSA; but not PKCS-1 RSA, the one interoperable algorithm that everyone is using presently! > > Hmm. > > I'm not necessarily advocating this position -- I might like to think about it some more myself -- but just for the sake of argument and to take the pulse, what would people think of making ANSI X9.31 RSA a MUST, X9.31 EC-DSA a SHOULD, and DSA and PKCS-1 RSA a MAY? > > It is my understanding that X9.31 RSA is considered to be superior to PKCS-1 RSA in terms of resistance to certain forms of attack, and should not be that great a stretch for existing RSA implementations, and hence the MUST. We wouldn't deprecate PKCS-1 RSA (at least not yet), since it must continue to be supported for backwards compatibility. > > This wouldn't deprecate DSA either, but it wouldn't be required for people outside of the (quite limited) community of interest presently using it. > > EC-DSA certainly beats regular DSA in terms of speed and size and deserves to be included in its own right, but I'm not entirely clear as to the patent situation, hence the SHOULD and not a MUST. > > In the area of symmetric algorithms, as soon as Rijndael is officially certified as the AES algorithm I believe we should promote AES to MUST, along with triple-DES and single DES for backwards compatibility. ( haven't heard of anyone clamoring for SKIPJACK, so I think it can safely be ignored in favor of triple-DES and/or AES.) > > Likewise, I think we will have to add SHA-386 and SHA-512 as MUST algorithms, along with SHA-1, and probably deprecate MD2 and MD5. > > What think ye? > > Bob > > > >Enzo has captured the chicken-and-egg essence of my concern. The U.S. > >Government has a requirement to purchase products which support FIPS > >186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1 > >RSA). And, at least in the DoD, we have requirements coming from our > >customers to be algorithm independent: > > > > "PKI must support a variety of public key cryptographic algorithms > > both in the public/private key pairs created and certified by PKI, > > and in the algorithms used to apply digital signatures to certificates > > and other PKI products. PKI must support the concurrent use of several > > digital signature algorithms for issuing certificates and must be able > > to migrate over time to using new signature algorithms." > > > > -- DoD PKI Operational Requirements Document, 22 October 2000 > > > > > >There is also the fact that DSA signatures are significantly smaller > >than RSA signatures, especially as we move to public keys above 1024 bits > >and the signature could be bigger than the entire to-be-signed certificate. > >This doesn't matter in many environments, but it does in some. > > > >If vendors look at what certificates have already been issued to decide > >what certificates to support in products under development, we will never > >evolve. I favor keeping DSA (in addition to RSA) as a MUST for S/MIME > >clients because algorithm independence is valuable in and of itself. > > > >Dave > > > > > > > >> From: "Enzo Michelangeli" > >> > >> Well, there is one problem, and it's due to the store-and-forwad nature of > >> e-mail which prevents negotiation, making it impossible to know whether a > >> given algorithm is supported by a new recipient (think, e.g., of signed > >> messages sent to mailing list). The result is that everybody ends up using > >> ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this > >> was precisely the root of the trouble with 40-bit security in the bad old > >> days: a sort of Grisham's Law for algorithms... > >> In my opinion, "MAY" algorithms are pretty useless in non-interactive > >> contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might > >> as well be dropped altogether. > >> > >> Enzo > > > From owner-ietf-smime Wed Nov 29 03:30:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01485 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:03 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01481 for ; Wed, 29 Nov 2000 03:30:02 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02003; Wed, 29 Nov 2000 06:31:31 -0500 (EST) Message-Id: <200011291131.GAA02003@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-compression-03.txt Date: Wed, 29 Nov 2000 06:31:31 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-03.txt Pages : Date : 28-Nov-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level) these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). This document defines a format for using compressed data as a CMS content type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134600.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 03:30:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01561 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:18 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01557 for ; Wed, 29 Nov 2000 03:30:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02154; Wed, 29 Nov 2000 06:31:45 -0500 (EST) Message-Id: <200011291131.GAA02154@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-x400transport-01.txt Date: Wed, 29 Nov 2000 06:31:45 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-01.txt Pages : Date : 28-Nov-00 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-x400transport-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-x400transport-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134631.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 03:30:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA01548 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:13 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01540 for ; Wed, 29 Nov 2000 03:30:12 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02101; Wed, 29 Nov 2000 06:31:41 -0500 (EST) Message-Id: <200011291131.GAA02101@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-x400wrap-01.txt Date: Wed, 29 Nov 2000 06:31:41 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400wrap-01.txt Pages : Date : 28-Nov-00 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-x400wrap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-x400wrap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 03:30:10 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA01523 for ietf-smime-bks; Wed, 29 Nov 2000 03:30:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01503 for ; Wed, 29 Nov 2000 03:30:07 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02047; Wed, 29 Nov 2000 06:31:37 -0500 (EST) Message-Id: <200011291131.GAA02047@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-05.txt Date: Wed, 29 Nov 2000 06:31:36 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-05.txt Pages : 8 Date : 28-Nov-00 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 05:26:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA09785 for ietf-smime-bks; Wed, 29 Nov 2000 05:26:30 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA09776 for ; Wed, 29 Nov 2000 05:26:27 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Nov 2000 13:27:48 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA13987; Wed, 29 Nov 2000 08:27:56 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 08:27:55 -0500 Message-ID: From: "Linn, John" To: "'Bob Jueneman'" Cc: ietf-smime@imc.org Subject: RE: RSA vs. DSA MUST Date: Wed, 29 Nov 2000 08:27:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, all: NIST's announcement of FIPS 186-2 (http://csrc.nist.gov/csrc/fedstandards.html) explicitly recognizes PKCS #1 for a transitional period through mid-2001. The topic of X9.31 vs. PKCS #1 was discussed at the June meeting of the U.S. Federal PKI Technical Working Group, leading to a recommendation which was to be communicated (see also minutes at http://csrc.nist.gov/pki/twg/y2000/twg00_6.htm) that FIPS 186-2 should be changed or interpreted to allow Federal use of PKCS #1 v. 1.5 for a significant additional period, perhaps 5 years or more, anticipating a migration after PSS signature definitions are suitably mature and stable. I don't know how this recommendation will act to impact the future of the FIPS 186 specification, but believe that it indicates an influential position from a significant U.S. Government user community. X9.31 doesn't appear to have been widely adopted, and I'm not aware that its padding structure offers security properties sufficiently different relative to PKCS #1 v. 1.5 to motivate a mandated switch to X9.31 (with associated installed base impact) at this point. A later migration to PSS, which affords qualitatively different provable security properties than either PKCS #1 v. 1.5 or X9.31 is, I believe, a more compelling case. --jl > -----Original Message----- > From: Bob Jueneman [mailto:bjueneman@novell.com] > Sent: Tuesday, November 28, 2000 6:34 PM > To: ietf-smime@imc.org; dpkemp@missi.ncsc.mil > Subject: Re: RSA vs. DSA MUST > > > Chicken and egg is exactly the situation we find ourselves > in. Implementors certainly want to support their customers, > but don't want to be "required" by standards to implement > algorithms that no one uses or are willing to pay for. > > Ozan Gonenc also makes a good point in suggesting that > perhaps the MUST algorithms be limited to FIPS approved > algorithms. I'm a slightly concerned that this may be too > US-centric a view, but on the other hand I haven't heard of > any other governments or customers requiring or promoting any > other algorithms, except for > unpublished/proprietary/classified algorithms used in certain > restricted sectors. (An exception might be GOST, but so far > we can't even get the Russians to agree to pay anything for > the capability., much less anyone else) So maybe limiting the > MUST algorithms to a subset of the FIPS-approved list is > acceptable. At least the FIPS listing implies a rather > serious degree of vetting as to the security of the > algorithms, which is something I don't think the IETF is > institutionally capable of, not withstanding the > cryptographic expertise of some of the members. > > The point about having at least one algorithm in the suite > that could be used if RSA were suddenly shown to be seriously > flawed is also valid, so long as we don't get carried away > with the list! > > FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic > Curve DSA; but not PKCS-1 RSA, the one interoperable > algorithm that everyone is using presently! > > Hmm. > > I'm not necessarily advocating this position -- I might like > to think about it some more myself -- but just for the sake > of argument and to take the pulse, what would people think of > making ANSI X9.31 RSA a MUST, X9.31 EC-DSA a SHOULD, and DSA > and PKCS-1 RSA a MAY? > > It is my understanding that X9.31 RSA is considered to be > superior to PKCS-1 RSA in terms of resistance to certain > forms of attack, and should not be that great a stretch for > existing RSA implementations, and hence the MUST. We wouldn't > deprecate PKCS-1 RSA (at least not yet), since it must > continue to be supported for backwards compatibility. > > This wouldn't deprecate DSA either, but it wouldn't be > required for people outside of the (quite limited) community > of interest presently using it. > > EC-DSA certainly beats regular DSA in terms of speed and size > and deserves to be included in its own right, but I'm not > entirely clear as to the patent situation, hence the SHOULD > and not a MUST. > > In the area of symmetric algorithms, as soon as Rijndael is > officially certified as the AES algorithm I believe we should > promote AES to MUST, along with triple-DES and single DES for > backwards compatibility. ( haven't heard of anyone clamoring > for SKIPJACK, so I think it can safely be ignored in favor of > triple-DES and/or AES.) > > Likewise, I think we will have to add SHA-386 and SHA-512 as > MUST algorithms, along with SHA-1, and probably deprecate MD2 and MD5. > > What think ye? > > Bob > > > >Enzo has captured the chicken-and-egg essence of my concern. > The U.S. > >Government has a requirement to purchase products which support FIPS > >186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but > not PKCS-1 > >RSA). And, at least in the DoD, we have requirements coming from our > >customers to be algorithm independent: > > > > "PKI must support a variety of public key cryptographic algorithms > > both in the public/private key pairs created and certified by PKI, > > and in the algorithms used to apply digital signatures to > certificates > > and other PKI products. PKI must support the concurrent > use of several > > digital signature algorithms for issuing certificates and > must be able > > to migrate over time to using new signature algorithms." > > > > -- DoD PKI Operational Requirements Document, 22 > October 2000 > > > > > >There is also the fact that DSA signatures are significantly smaller > >than RSA signatures, especially as we move to public keys > above 1024 bits > >and the signature could be bigger than the entire > to-be-signed certificate. > >This doesn't matter in many environments, but it does in some. > > > >If vendors look at what certificates have already been > issued to decide > >what certificates to support in products under development, > we will never > >evolve. I favor keeping DSA (in addition to RSA) as a MUST > for S/MIME > >clients because algorithm independence is valuable in and of itself. > > > >Dave > > > > > > > >> From: "Enzo Michelangeli" > >> > >> Well, there is one problem, and it's due to the > store-and-forwad nature of > >> e-mail which prevents negotiation, making it impossible to > know whether a > >> given algorithm is supported by a new recipient (think, > e.g., of signed > >> messages sent to mailing list). The result is that > everybody ends up using > >> ONLY the common denominator, i.e. the "MUST" algorithms. > Incidentally, this > >> was precisely the root of the trouble with 40-bit security > in the bad old > >> days: a sort of Grisham's Law for algorithms... > >> In my opinion, "MAY" algorithms are pretty useless in > non-interactive > >> contexts, and if DSA is not kept as a "MUST" (my preferred > choice), it might > >> as well be dropped altogether. > >> > >> Enzo > > > From owner-ietf-smime Wed Nov 29 08:57:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25376 for ietf-smime-bks; Wed, 29 Nov 2000 08:57:25 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25371 for ; Wed, 29 Nov 2000 08:57:24 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 29 Nov 2000 09:58:16 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 29 Nov 2000 09:58:15 -0700 From: "Bob Jueneman" To: , , Subject: SMIMECapabilites for AES, etc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA25372 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Although it isn't strictly interactive in the sense that SSL is, >> the SMIMECapabilities attribute allows the originator of a message >> to indicate his preference as to encryption algorithms, including >> 40-bit RC4 vs. 56-bit DES > vs. 128-bit whatever vs. 196-bit >> triple-DES (and soon, presumably, 256-bit AES). > >Yes, but on the open Internet most certificates are sent as part of the >message (presently in PKCS#7 format), not retrieved from global directories >as the X.500 folks initially hoped. In that context, the recipient would >have to send an initial signed message to the sender to indicate the user >agent's capabilities: and in most cases (like one I mentioned of the mailing >list) that's just not viable. > >Enzo > > You are correct, of course. I was thinking about the encryption case, primarily, where it is much more likely that the recipients would have exchanged at least a signed message, precisely in order to exchange certificates. That does bring up a good point regarding AES, however. In the past, it was usually possible to make a good guess as to whether to use a 40-bit key (RC2 or RC4) or a full strength key (DES, triple-DES, or perhaps 128-bit RC2 or RC4) based on what you knew about the recipient, in particular whether he or she was in the US or Canada, or somewhere else that was more likely to be subject to export controls. And nearly all of the e-mail packages implemented RC2 and RC4, and the "domestic-strength" packages implemented both DES and triple-DES. So the SMIMECapabilities attribute wasn't really all that necessary. As we begin the transition to AES, however, that won't be the case. There will be a substantial number of packages that support triple-DES but haven't been upgraded to AES, and I would expect that situation to last for a couple of years or more. So anyone who simply fires off a message encrypted in AES without checking first is taking the risk that his message can't be read. In order to facilitate an orderly transition, I would suggest that we specify a date certain, after which the default algorithm would be 256-bit AES, rather than triple-DES. That certainly wouldn't be difficult to implement. Assuming that AES is formally endorsed some time in the next couple of months (I don't know the exact time line they are on), what would people think about April 1, 2004? That would provide a generous 18 months for a vendor to release their next version, and another 18+ months for users to adopt it. Since most e-mail packages are based on underlying crypto packages that can be downloaded via the web, I think that would be more than enough time. Of course if someone chooses to do so, they can explicitly request (or force) the use of AES prior to that date, but at least the default would be taken care of nicely. Bob From owner-ietf-smime Wed Nov 29 10:09:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00138 for ietf-smime-bks; Wed, 29 Nov 2000 10:09:35 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA00132 for ; Wed, 29 Nov 2000 10:09:34 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Wed, 29 Nov 2000 10:10:34 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 10:10:34 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C5A775B8@mail.deming.com> From: "Blake Ramsdell" To: "'pgut001@cs.aucKland.ac.nz'" , bjueneman@novell.com, dpkemp@missi.ncsc.mil, ietf-smime@imc.org Subject: RE: RSA vs. DSA MUST Date: Wed, 29 Nov 2000 10:10:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 163B991038585-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An inimitable Gutmannism. This could also be summarized as Paul did it when we first started this discussion back in July: > Blake Ramsdell has turned in two drafts that are worthy of > consideration in this group. It's my opinion that they represent the > reality of the marketplace, and that it would be good to have our > RFCs reflect that if possible. Which was exactly my intent. There seems to be some disconnect between the current discussion and the strawpoll consensus at the last IETF, which needs to be resolved, however. I would certainly welcome how I should interpret "BWAHAHAHAHAHA" in the context of MUST and SHOULD, however. Blake -----Original Message----- From: pgut001@cs.aucKland.ac.nz [mailto:pgut001@cs.aucKland.ac.nz] Sent: Wednesday, November 29, 2000 6:44 AM To: bjueneman@novell.com; dpkemp@missi.ncsc.mil; ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST "Bob Jueneman" writes: >I'm not necessarily advocating this position -- I might like to think about it >some more myself -- but just for the sake of argument and to take the pulse, >what would people think of making ANSI X9.31 RSA a MUST, X9.31 EC-DSA a >SHOULD, and DSA and PKCS-1 RSA a MAY? How about trying to make the spec at least vaguely approximate reality in the choice of algorithms? It doesn't really matter if you include requirements like "MUST DSA OR WE WILL KILL YOU[0], SHOULD NOT RSA", in practice the world will interpret it as "MUST RSA, MAY DSA, SHOULD NOT X9.42 DH, BWAHAHAHAHAHA X9.31 RSA" no matter what it says in the RFC (I think IBM does X9.31 in CCA but does anything else in existence implement this?). I've been sitting here watching this debate go on and on, but since no matter what you put in the RFC the market will interpret it as MUST RSA and various levels of deprecation for anything else maybe we could get Markov Chaney to continue the debate for a while just for forms sake and then after enough messages have been exchanged to satisfy everyone either put text in the RFC which accepts what everyone's going to do anyway or which specifies all sorts of options and alternatives secure in the knowledge that implementors will ignore it and do what the market wants/expects, which ain't DSA or X9.31 RSA. Peter. [0] RFC 2026bis, "When MUST just isn't enough". From owner-ietf-smime Wed Nov 29 12:20:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08769 for ietf-smime-bks; Wed, 29 Nov 2000 12:20:48 -0800 (PST) Received: from smtp01.infoave.net (smtp01.infoave.net [165.166.0.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08756 for ; Wed, 29 Nov 2000 12:20:46 -0800 (PST) Received: from linus.corecom.com ([64.53.5.179]) by SMTP00.InfoAve.Net (PMDF V5.2-33 #45321) with ESMTP id <01JX485HPKEG9AO0JU@SMTP00.InfoAve.Net> for ietf-smime@imc.org; Wed, 29 Nov 2000 15:22:16 EDT Date: Wed, 29 Nov 2000 15:23:27 -0500 From: Dave Piscitello Subject: TISC 2001 Call for Papers, Session Abstracts X-Sender: dave@corecom.com@mail2.netreach.net To: ietf-smime@imc.org Message-id: <4.3.2.7.2.20001129152226.00bd0af0@mail2.netreach.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, The Fifth Internet Security Conference will be held June 4-8, 2001 at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars, Century City Los Angeles, CA 90067-4696. TISC is an educational forum for security professionals and practitioners. The TISC Security Symposium is an opportunity for individuals to share their expertise and practical experience with others involved in the design, implementation and deployment of networked security systems. We cordially invite you to submit an abstract for an original paper. Accepted papers will be presented at the conference. We also invite you to submit a session abstract for consideration, or if you prefer, to present a topic as a panel member. We encourage you to submit abstracts and topics by December 8. Further information can be found at http://tisc.corecom.com. Or send your proposal to me at mailto:dave@corecom.com. We look forward to your participation. Thank you. Warm Regards, Dave Piscitello On behalf of the TISC Advisory Board David M. Piscitello Core Competence, Inc. (http://www.corecom.com) and The Internet Security Conference (http://tisc.corecom.com) ~~ The Internet has security problems. We have answers. ~~ 3 Myrtle Bank Lane dave@corecom.com Hilton Head, SC 29926 1.843.683-9988 PGP Fingerprint: 070A 9F01 C35C 4D41 A460 EF2C 2992 2F12 11D2 02DC From owner-ietf-smime Wed Nov 29 13:57:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14577 for ietf-smime-bks; Wed, 29 Nov 2000 13:57:34 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14573 for ; Wed, 29 Nov 2000 13:57:32 -0800 (PST) Received: from ieca.com (mva-aa-086.capu.net [207.226.159.86]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id QAA24513 for ; Wed, 29 Nov 2000 16:59:04 -0500 Message-ID: <3A257C22.D2AB9DE5@ieca.com> Date: Wed, 29 Nov 2000 16:58:58 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made. These are (employing a little editorial license): * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost has gone up into the "too high" range. * Specifying a single MUST algorithm suite was sufficient to make S/MIME algorithm independent, but actually requiring two algorithms suites will cost too much. If we've really achieved algorithm independence in the sense that Dave Kemp suggests, this should be a debate about a relatively small math module. * We have an 'SMIMECapabilities' attribute for which support is MUST, but some implementations ignore it so we have to use the lowest common denominator to force interoperability. What make anybody think a MUST on an algorithm choice would be taken any more seriously? I don't think I actually have an opinion on this issue myself. I'm of the mindset to mandate nothing and let Darwin decide. However, I find the seeming illogic of these collective opinions very troubling. It leads me to think that we're not getting to the REAL reasoning behind this move. I think Blake was closest to this in stating that there has been no customer demand for DSA. Is this the REAL reason to dump DSA? Are customers demanding RSA be used? Do customers express demand for any algorithms, or do they just want it to be "secure"? Are we just drifting to the path of least resistance? Personally, I favor products that support LOTS of interoperability modes... not just lowest common denominators. Call me crazy, but... Chris B. From owner-ietf-smime Wed Nov 29 15:13:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16860 for ietf-smime-bks; Wed, 29 Nov 2000 15:13:32 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16856 for ; Wed, 29 Nov 2000 15:13:32 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (dial04.spyrus.com [207.212.34.124]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id PAA01758; Wed, 29 Nov 2000 15:13:26 -0800 (PST) Message-Id: <5.0.1.4.2.20001129175648.0289b0c0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 29 Nov 2000 18:00:44 -0500 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: IESG ACTION NEEDED: draft-ietf-smime-compression-03.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff & Marcus: The S/MIME WG has finished work on the CMS compressed data type. This Interned-Draft is ready for IETF Last Call and approval by the IESG as a standards-track RFC. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-03.txt Date : 28-Nov-00 RFC 2630 (CMS) doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level) these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). This document defines a format for using compressed data as a CMS content type. Russ From owner-ietf-smime Wed Nov 29 15:18:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA17335 for ietf-smime-bks; Wed, 29 Nov 2000 15:18:15 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17331 for ; Wed, 29 Nov 2000 15:18:14 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 29 Nov 2000 16:18:46 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 29 Nov 2000 16:18:47 -0700 From: "Bob Jueneman" To: , Subject: Re: RSA vs. DSA MUST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA17332 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, I believe these points are important, and perhaps more important than the particular issues at hand. So please allow me to wax philosophical. As a consumer, all things being equal, I like products that support lots of interoperability modes too. Beer, champagne, hot dogs, filet mignon, ice cream, apple pie, floor wax and desert topping -- they're all great, at least if you can afford them. But as a vendor, I am increasingly concerned about the amount of feature creep that we are seeing every day in both the PKIX and SMIME groups, apparently almost unconstrained by business requirements. We need interoperability, and that should not mean lowest common denominator, but it also shouldn't mean being all things to all men. Although the development cost of adding a particular feature tends to go up linearly, the testing and interoperability costs tend to go up with the SQUARE of the features, all of which generally have to be tested in all possible combinations. That is both expensive and time consuming, and leads to products that are either buggy or late, or typically both. And that clearly doesn't benefit the consumer at all. As a result, Product Management is increasingly inclined to "Just Say NO" to these kinds of features, which ends up making IETF standards increasingly irrelevant and making interoperability that much harder, rather than easier. The real challenge in creating standards is therefore not to attempt to see how many you can create with all of their rococo variations, but rather how few you can get by with and still get the job done. To the extent that the IETF WGs become self-justifying, self-perpetuating, and eternal, the less useful they become, IMHO. We are becoming more and more like ISO every day, and maybe worse. Now allow me to (gently, I hope) take issue with some of your other statements: > >>>> "Bonatti, Chris" 11/29/00 02:58PM >>> > Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made. These are >(employing a little editorial license): > > * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost >has gone up into the "too high" range. I would disagree. The cost of the RSA license was minimal relative to other development costs, and the RSA algorithm was effectively all there was in terms of deployed PKI infrastructure. The fact that DSA and D-H were labeled MUST was chalked up to IETF politics, and completely ignored by the vendor community as not being worth the implementation cost in terms of revenue return. Granted, it didn't meet some of the expressed desires of the US Government, but the USG has always had a much bigger appetite than budget. (Remember Jovial? Ada? C2 by '92?) Money talks, and everything else walks. They imposed requirements, but those requirements didn't stick when it came to real procurements. > > * Specifying a single MUST algorithm suite was sufficient to make S/MIME algorithm independent, but actually requiring two algorithms suites will cost too >much. If we've really achieved algorithm independence in the sense that Dave Kemp suggests, this should be a debate about a relatively small math module. No, again I disagree. The math module isn't the problem. As a BSAFE licensee, we already have all of the math modules we would need. The real issue is all of the multitudinous GUI screens that have to be developed to allow the user to choose this, that or the other algorithm within S/MIME, and then the same set of choices in any PKI products, and then testing all of these options in every conceivable combination, not just within a given product but in combination with all of the other leading e-mail packages, plus the various PKI services and toolkits as well. those costs dwarf the cost of the math module by a couple of orders of magnitude. > * We have an 'SMIMECapabilities' attribute for which support is MUST, but some implementations ignore it so we have to use the lowest common >denominator to force interoperability. What make anybody think a MUST on an algorithm choice would be taken any more seriously? Two issues. As I recall, the SMIMECapabilities is a MAY, not a MUST, although I'll stand corrected if I'm wrong. And as I say, and Peter Gutmann said more succinctly, MUST matters if and only if the vendor was inclined to implement that option anyway. It might be sufficient to push someone over the fence who was already 49% there, but not much more. Standards compliance doesn't pay the rent -- customers do. > > I don't think I actually have an opinion on this issue myself. I'm of the mind set to mandate nothing and let Darwin decide. However, I find the seeming >illogic of these collective opinions very troubling. It leads me to think that we're not getting to the REAL reasoning behind this move. > > I think Blake was closest to this in stating that there has been no customer demand for DSA. Is this the REAL reason to dump DSA? Are customers >demanding RSA be used? Do customers express demand for any algorithms, or do they just want it to be "secure"? Are we just drifting to the path of least >resistance? Customers don't demand or specify algorithms. They just want it to be secure, and trust that the vendor will figure out what that means. What they do insist on, however, is that the product work well with the existing infrastructure in order to reduce their total overall cost of ownership. The more sophisticated customers realize that adding more and more features that they never use significantly increases that TCO, so overburdening a product with unnecessary features causes a significant backlash. Increased cost of development with decreased sales. What a concept! > > Personally, I favor products that support LOTS of interoperability modes... not just lowest common denominators. Call me crazy, but... > >Chris B. This is really a case of Little Red Riding Hood's porridge. We want it to be not too hot (needlessly feature rich), and not too cold (missing important capabilities or security, forcing everyone to devolve to the lowest common denominator), but rather just right. And that requires making intelligent CHOICES. I like mustard, and I like chocolate. But that doesn't mean that I want chocolate on my hot dog, nor mustard on my ice cream, just because I have them both in my refrigerator. :-) Regards, Bob From owner-ietf-smime Wed Nov 29 16:03:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19961 for ietf-smime-bks; Wed, 29 Nov 2000 16:03:59 -0800 (PST) Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA19956 for ; Wed, 29 Nov 2000 16:03:58 -0800 (PST) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 011686078; Wed, 29 Nov 2000 19:05:31 -0500 (EST) Received: from caveosystems.com (adsl-141-154-13-230.bellatlantic.net [141.154.13.230]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id TAA15777; Wed, 29 Nov 2000 19:06:06 -0500 Message-ID: <3A259A89.726BBA61@caveosystems.com> Date: Wed, 29 Nov 2000 19:08:41 -0500 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bonatti, Chris" CC: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: <3A257C22.D2AB9DE5@ieca.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think your perception is slightly (but significantly) off. Some folks implemented DSA-family, but most folks paid money and licensed RSA and did that. Apparently some of those DSA implementors would rather not bear the continued cost of maintaining a code branch that has seen no customer demand. That's a high cost just to be able to claim IETF SMIME compliance. To be algorithm independant, you make sure you always identify the algorithm, and don't mistakenly say "encrypted data" without specifying the mechanism. During development of the standards, a good way to do that is to make sure multiple mechanisms are specified. In this case, the theoretical (DSA) and the practical (RSA). Peter Gutman said it best a few weeks ago, shortly after RSA expired. Something along the lines of "we all pretended to do DSA, but in reality everyone did RSA." For political reasons, the IETF bent over backwards to avoid mandating patented technology. >Personally, I favor products that support LOTS of interoperability modes. That's nonsensical. Do you prefer BER over DER? :) The marketplace has decided and the common crypto mechanism is RSA, and practically nobody cares about DSA. Certainly, making DSA not MUST will not hurt the DSA-using community. It's not the IETF's job to raise the bar. It's the IETF's job to make sure we all speak the same language, and clearly that language is mod-exp. /r$ From owner-ietf-smime Wed Nov 29 16:16:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20241 for ietf-smime-bks; Wed, 29 Nov 2000 16:16:36 -0800 (PST) Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20237 for ; Wed, 29 Nov 2000 16:16:35 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 141HQM-0000ko-0A for ietf-smime@imc.org; Thu, 30 Nov 2000 00:18:07 +0000 Message-ID: <3A259CAA.79D5024E@celocom.com> Date: Thu, 30 Nov 2000 00:17:46 +0000 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: <3A257C22.D2AB9DE5@ieca.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bonatti, Chris" wrote: > > Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made. These are (employing a little editorial license): > > * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost has gone up into the "too high" range. > I'd say in the DH case (and to some extent DSA) there's the issue of how practical it is. The only DH certificates I've ever seen were in the S/MIME examples draft. I suspect there are problems with the parameters but despite repeated queries I never found anyone who could independently check them. If public CAs issuing DSA certificates are rare then I'd say CAs issuing DH certificates are virtually non existent. Does anyone know of a single example? Its all very nice adding support for DSA and DH but if users can't get any certificates from public CAs then their value is severely limited. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime Wed Nov 29 17:19:36 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA21745 for ietf-smime-bks; Wed, 29 Nov 2000 17:19:36 -0800 (PST) Received: from bbs.ht.net.cn ([202.103.160.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21740 for ; Wed, 29 Nov 2000 17:19:34 -0800 (PST) From: V@tzw.de Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id JAA15367; Thu, 30 Nov 2000 09:38:25 +0800 Date: Thu, 30 Nov 2000 09:38:25 +0800 Message-Id: <200011300138.JAA15367@bbs.ht.net.cn> To: V@tzw.de Subject: Lady V: The Pleasure Pill for Women! Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LADY V: The Pleasure Pill for Women! Men Have Their Viagra®! Finally, A Pill for Women! It's Here! The Revolutionary Woman's Sexual Sensation is Now Available. Researchers are calling Lady V the greatest breakthrough for women since the Birth Control Pill. And you don't even need a prescription to get it! Welcome to the New Sexual Revolution! It's no secret that men have been having the time of their lives since the wonder pill Viagra® was made available. But, women were left out in the cold with no pill... nothing! Well now thanks to an all-star team of medical researchers who have been working around the clock, those days are finally over. The perfect female "pleasure pill" has been created and you don't even need a prescription. You can now get it from Lion Sciences! Lady V is the world's first pleasure pill scientifically designed for women. Lady V is an all-natural proprietary herbal blend of prosexual nutrients from around the world synergistically blended to naturally stimulate neurotransmitter endorphin signals. This magical combination increases targeted blood flow, unleashes natural stimulator for maximum stimulation, triggering pleasure responses quickly. Lady V is safe, natural and doctor-recommended. Since its introduction Lady V has been taking the world by storm! >From Malibu to Miami women are enjoying the most intense pleasure of their lives! • 100% Natural • Safe • The Highest Quality Pharmaceutical Pure Nutraceuticals • Guaranteed Potency • Certified Purity Lady V is Sweeping the Nation! Women are going crazy over Lady V. Suddenly couples are falling in love all over again. The passion and pleasure that women are reporting is off the charts! Lady V has an incredible 88% success rate. Best of all, while Viagra costs $10 a pill, Lady V costs less than $1 a pill! It's not just a man's world anymore! Just look at what a few women have to say: "I thought my love life was good before, but now it is out of this world! Lady V is remarkable." — Mary J., Interior Designer "I haven't smiled like this in a long time. My husband and I feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer "Imagine what it would feel like to have incredible passion and pleasure anytime you want." — Jennifer C., Film Editor "Suddenly my husband and I are spending more time in the bedroom instead of the TV room." — Angie R., Realtor Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid, Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract, Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana, and L-Taurine. Each bottle of Lady V contains 30 tablets. Take three capsules one hour before romantic activity as a dietary supplement. Risk Free: Double Your Money Back Guarantee If Lady V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked! Order Now: Safe, Fast, Secure, Private Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Lady V contains 30 tablets. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Lady V $24 ______ 2 Bottles of Lady V $44 ______ 3 Bottles of Lady V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Lady V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Lady V helps provide herbal and nutritional support for female sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-smime Wed Nov 29 17:58:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22779 for ietf-smime-bks; Wed, 29 Nov 2000 17:58:55 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22775 for ; Wed, 29 Nov 2000 17:58:54 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU20R429348; Wed, 29 Nov 2000 19:00:27 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDVf23697 for ; Wed, 29 Nov 2000 15:13:31 -0700 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDUf27814 for ; Wed, 29 Nov 2000 15:13:30 -0700 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14577 for ietf-smime-bks; Wed, 29 Nov 2000 13:57:34 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14573 for ; Wed, 29 Nov 2000 13:57:32 -0800 (PST) Received: from ieca.com (mva-aa-086.capu.net [207.226.159.86]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id QAA24513 for ; Wed, 29 Nov 2000 16:59:04 -0500 Message-ID: <3A257C22.D2AB9DE5@ieca.com> Date: Wed, 29 Nov 2000 16:58:58 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-smime Wed Nov 29 18:06:18 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA22983 for ietf-smime-bks; Wed, 29 Nov 2000 18:06:18 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22964 for ; Wed, 29 Nov 2000 18:06:11 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU20xk30850; Wed, 29 Nov 2000 19:00:59 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMZf26535; Wed, 29 Nov 2000 15:22:35 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMXf29458; Wed, 29 Nov 2000 15:22:33 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA06503 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 17:05:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01536 for ; Wed, 29 Nov 2000 06:31:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02047; Wed, 29 Nov 2000 06:31:37 -0500 (EST) Message-Id: <200011291131.GAA02047@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-05.txt Date: Wed, 29 Nov 2000 06:31:36 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-05.txt Pages : 8 Date : 28-Nov-00 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 18:06:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA22972 for ietf-smime-bks; Wed, 29 Nov 2000 18:06:13 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22961 for ; Wed, 29 Nov 2000 18:06:11 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU20XQ29644; Wed, 29 Nov 2000 19:00:33 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEgf24308; Wed, 29 Nov 2000 15:14:42 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEff28052; Wed, 29 Nov 2000 15:14:41 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06414 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:55:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01529 for ; Wed, 29 Nov 2000 06:31:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02003; Wed, 29 Nov 2000 06:31:31 -0500 (EST) Message-Id: <200011291131.GAA02003@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-compression-03.txt Date: Wed, 29 Nov 2000 06:31:31 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-03.txt Pages : Date : 28-Nov-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level) these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). This document defines a format for using compressed data as a CMS content type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134600.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 18:37:01 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA23994 for ietf-smime-bks; Wed, 29 Nov 2000 18:37:01 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23990 for ; Wed, 29 Nov 2000 18:36:59 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2cXb13973; Wed, 29 Nov 2000 19:38:33 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDVf23697 for ; Wed, 29 Nov 2000 15:13:31 -0700 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMDUf27814 for ; Wed, 29 Nov 2000 15:13:30 -0700 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14577 for ietf-smime-bks; Wed, 29 Nov 2000 13:57:34 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14573 for ; Wed, 29 Nov 2000 13:57:32 -0800 (PST) Received: from ieca.com (mva-aa-086.capu.net [207.226.159.86]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id QAA24513 for ; Wed, 29 Nov 2000 16:59:04 -0500 Message-ID: <3A257C22.D2AB9DE5@ieca.com> Date: Wed, 29 Nov 2000 16:58:58 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-smime Wed Nov 29 19:00:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA24387 for ietf-smime-bks; Wed, 29 Nov 2000 19:00:04 -0800 (PST) Received: from mailhost3.lanl.gov (mailhost3.lanl.gov [128.165.3.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24383 for ; Wed, 29 Nov 2000 19:00:02 -0800 (PST) Received: (from root@localhost) by mailhost3.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2vRJ12068; Wed, 29 Nov 2000 19:57:27 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailhost3.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMVG419269; Wed, 29 Nov 2000 15:31:17 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMVEf31198; Wed, 29 Nov 2000 15:31:14 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA06575 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 17:15:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01543 for ; Wed, 29 Nov 2000 06:31:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02101; Wed, 29 Nov 2000 06:31:41 -0500 (EST) Message-Id: <200011291131.GAA02101@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-x400wrap-01.txt Date: Wed, 29 Nov 2000 06:31:41 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400wrap-01.txt Pages : Date : 28-Nov-00 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-x400wrap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-x400wrap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 18:59:37 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA24375 for ietf-smime-bks; Wed, 29 Nov 2000 18:59:37 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24370 for ; Wed, 29 Nov 2000 18:59:35 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2gAQ16496; Wed, 29 Nov 2000 19:42:10 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMZf26535; Wed, 29 Nov 2000 15:22:35 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMMXf29458; Wed, 29 Nov 2000 15:22:33 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id RAA06503 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 17:05:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01536 for ; Wed, 29 Nov 2000 06:31:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02047; Wed, 29 Nov 2000 06:31:37 -0500 (EST) Message-Id: <200011291131.GAA02047@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-05.txt Date: Wed, 29 Nov 2000 06:31:36 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-05.txt Pages : 8 Date : 28-Nov-00 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 18:59:29 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA24368 for ietf-smime-bks; Wed, 29 Nov 2000 18:59:29 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24364 for ; Wed, 29 Nov 2000 18:59:28 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2dG814653; Wed, 29 Nov 2000 19:39:16 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEgf24308; Wed, 29 Nov 2000 15:14:42 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATMEff28052; Wed, 29 Nov 2000 15:14:41 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06414 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:55:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01529 for ; Wed, 29 Nov 2000 06:31:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02003; Wed, 29 Nov 2000 06:31:31 -0500 (EST) Message-Id: <200011291131.GAA02003@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-compression-03.txt Date: Wed, 29 Nov 2000 06:31:31 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-03.txt Pages : Date : 28-Nov-00 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level) these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). This document defines a format for using compressed data as a CMS content type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134600.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Wed Nov 29 20:21:17 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA28359 for ietf-smime-bks; Wed, 29 Nov 2000 20:21:17 -0800 (PST) Received: from china.asiainter.net (asiainter.net [202.84.207.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA28354 for ; Wed, 29 Nov 2000 20:21:15 -0800 (PST) Received: (qmail 1233 invoked from network); 30 Nov 2000 04:22:44 -0000 Received: from unknown (HELO em) (203.161.252.186) by asiainter.net with SMTP; 30 Nov 2000 04:22:44 -0000 Message-ID: <008701c05a85$245f00d0$6000a8c0@em> From: "Enzo Michelangeli" To: "Bob Jueneman" , "Bonatti, Chris" , References: Subject: Re: RSA vs. DSA MUST Date: Thu, 30 Nov 2000 11:59:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Original Message ----- From: "Bob Jueneman" To: ; Sent: Thursday, November 30, 2000 7:18 AM Subject: Re: RSA vs. DSA MUST [...] > As a result, Product Management is increasingly inclined to > "Just Say NO" to these kinds of features, which ends up making > IETF standards increasingly irrelevant and making interoperability > that much harder, rather than easier. I think that Product Management needs to understand that in the Internet age interoperability is, for a vendor, matter of life and death; I think your company grasps this point well, as it bit the bullet several years ago by embracing TCP/IP. > The real challenge in creating standards is therefore not to > attempt to see how many you can create with all of their rococo > variations, but rather how few you can get by with and still > get the job done. To the extent that the IETF WGs become > self-justifying, self-perpetuating, and eternal, the less useful > they become, IMHO. We are becoming more and more like ISO every > day, and maybe worse. Gee Bob, you stole my line: I was planning to title one of my postings "The X.400-ization of secure e-mail". Does everyboy remember X.400 (1984) and X.400 (1988)? Both S/MIME and OpenPGP, at this moment, exist in two major versions that do not necessarily interoperate with each other, and for the same damn reason (old intellectual property issues on cryptographic algorithms, now in large part disappeared). > This is really a case of Little Red Riding Hood's porridge. > We want it to be not too hot (needlessly feature rich), and > not too cold (missing important capabilities or security, > forcing everyone to devolve to the lowest common denominator), > but rather just right. And that requires making intelligent CHOICES. Here is my modest proposal for SMIME v.3 sole MUST requirements: - Full interoperability with SMIME v.2, therefore #include-ing all the MUST of RFC2311; - Minimum key length raised to 1024-bit for PK and 112-bit for symmetric algorithms; - At least one other key exchange algorithm and one signature algorithm unrelated to the problem of modular factorization, to protect against possible unpleasant effects of progress in numbers theory. I'd say that DSA and DH are the best candidates, if we want to exorcise the IP curse that could strike ECC-based techniques; - 3DES-EDE and Rijndael added to RC2. Cheers -- Enzo From owner-ietf-smime Thu Nov 30 02:56:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27612 for ietf-smime-bks; Thu, 30 Nov 2000 02:56:09 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27592 for ; Thu, 30 Nov 2000 02:56:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28262; Thu, 30 Nov 2000 05:57:39 -0500 (EST) Message-Id: <200011301057.FAA28262@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-esformats-02.txt Date: Thu, 30 Nov 2000 05:57:38 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Electronic Signature Formats for long term electronic signature Author(s) : D. Pinkas, J. Ross, N. Pope Filename : draft-ietf-smime-esformats-02.txt Pages : 75 Date : 29-Nov-00 The informational RFC defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e. repudiates, see [ISONR]) the validity of the signature. The format can be considered as an extension to RFC 2630 [CMS] and RFC 2634 [ESS], where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC is technically equivalent to ETSI ES 201 733 V.1.1.3 Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-esformats-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-esformats-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-esformats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-esformats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114644.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime Thu Nov 30 07:19:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18835 for ietf-smime-bks; Thu, 30 Nov 2000 07:19:26 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18829 for ; Thu, 30 Nov 2000 07:19:25 -0800 (PST) Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20115; Thu, 30 Nov 2000 10:21:00 -0500 Message-ID: <3A26705C.EA9CD47A@ieca.com> Date: Thu, 30 Nov 2000 10:21:00 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rich Salz CC: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: <3A257C22.D2AB9DE5@ieca.com> <3A259A89.726BBA61@caveosystems.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rich Salz wrote: > To be algorithm independant, you make sure you always identify the algorithm, > and don't mistakenly say "encrypted data" without specifying the mechanism. > During development of the standards, a good way to do that is to make sure > multiple mechanisms are specified. In this case, the theoretical (DSA) and the > practical (RSA). > I had the sense that what Dave was alluding to was something more. It sounds like an algorithm independent infrastructure, or maybe a multi-algorithm infrastructure is a better way to say it. (Dave, I don't want to put words in your mouth, but it seemed to me this is what your 11/28 message was saying.) This strikes me as a good idea from a robustness point of view as has already been stated. It seems like we're saying on the one hand that this is a good idea, yet on the other that everybody building to a lowest common denominator is all we're willing to do. That seems a little disconnected to me. > > Peter Gutman said it best a few weeks ago, shortly after RSA expired. > Something along the lines of "we all pretended to do DSA, but in reality > everyone did RSA." For political reasons, the IETF bent over backwards to > avoid mandating patented technology. > I missed this statement the first time around, but I think it's probably accurate. However, consider just what it says about IETF's overall impact on industry. I think we take the whole MUST/SHOULD/MAY debate way too seriously. Industry does what it wants. > > >Personally, I favor products that support LOTS of interoperability modes. > > That's nonsensical. Do you prefer BER over DER? :) > For some things, yes. It's better for one-pass processing for instance. > > The marketplace has decided and the common crypto mechanism is RSA, and > practically nobody cares about DSA. Certainly, making DSA not MUST will not > hurt the DSA-using community. > > It's not the IETF's job to raise the bar. It's the IETF's job to make sure we > all speak the same language, and clearly that language is mod-exp. > /r$ I agree on these points. Cheers, Chris B. From owner-ietf-smime Thu Nov 30 07:20:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18919 for ietf-smime-bks; Thu, 30 Nov 2000 07:20:03 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18912 for ; Thu, 30 Nov 2000 07:20:02 -0800 (PST) Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20188; Thu, 30 Nov 2000 10:21:32 -0500 Message-ID: <3A26707C.CCEE0CA0@ieca.com> Date: Thu, 30 Nov 2000 10:21:32 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Enzo Michelangeli CC: Bob Jueneman , ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: <008701c05a85$245f00d0$6000a8c0@em> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Enzo Michelangeli wrote: > Here is my modest proposal for SMIME v.3 sole MUST requirements: > > - Full interoperability with SMIME v.2, therefore #include-ing all the MUST > of RFC2311; > - Minimum key length raised to 1024-bit for PK and 112-bit for symmetric > algorithms; > - At least one other key exchange algorithm and one signature algorithm > unrelated to the problem of modular factorization, to protect against > possible unpleasant effects of progress in numbers theory. I'd say that DSA > and DH are the best candidates, if we want to exorcise the IP curse that > could strike ECC-based techniques; > - 3DES-EDE and Rijndael added to RC2. > > Cheers -- > > Enzo Enzo, This isn't actually too modest in my view. In terms of numbers of things supported it's not too far from where we are now (just a few attributes). I would support this with one addition. I think you *need* to support the 'SMIMECapabilities' on reception. This just seems like a necessity in any environment that supports multiple algorithms. Otherwise, you have all you need for basic interoperability. Chris From owner-ietf-smime Thu Nov 30 07:19:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18892 for ietf-smime-bks; Thu, 30 Nov 2000 07:19:52 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18885 for ; Thu, 30 Nov 2000 07:19:51 -0800 (PST) Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20162; Thu, 30 Nov 2000 10:21:23 -0500 Message-ID: <3A267073.2B9437D9@ieca.com> Date: Thu, 30 Nov 2000 10:21:23 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dr S N Henson CC: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: <3A257C22.D2AB9DE5@ieca.com> <3A259CAA.79D5024E@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dr S N Henson wrote: > "Bonatti, Chris" wrote: > > > > Reading through this thread, I am astonished at a couple of apparent truisms that are emerging from the various earnest statements made. These are (employing a little editorial license): > > > > * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost has gone up into the "too high" range. > > > > I'd say in the DH case (and to some extent DSA) there's the issue of how > practical it is. The only DH certificates I've ever seen were in the > S/MIME examples draft. I suspect there are problems with the parameters > but despite repeated queries I never found anyone who could > independently check them. > I agree about D-H certs. They are not deployed as far as I can see. > > If public CAs issuing DSA certificates are rare then I'd say CAs issuing > DH certificates are virtually non existent. Does anyone know of a single > example? > For "public CAs" I'd have to agree. I think the US government has issued *lots* of DSA certs, but they generally don't emit them because the interoperability picture is rather bleak. I don't think secure mail gets used much outside of fairly closed environments for this very reason. It's exceedingly rare that I even see a signed message in this forum. > > Its all very nice adding support for DSA and DH but if users can't get > any certificates from public CAs then their value is severely limited. > It's a bit of a chicken and egg problem, though. Chris > > Steve. > -- > Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ > Personal Email: shenson@drh-consultancy.demon.co.uk > Senior crypto engineer, Celo Communications: http://www.celocom.com/ > Core developer of the OpenSSL project: http://www.openssl.org/ > Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime Thu Nov 30 07:19:25 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA18825 for ietf-smime-bks; Thu, 30 Nov 2000 07:19:25 -0800 (PST) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18815 for ; Thu, 30 Nov 2000 07:19:22 -0800 (PST) Received: from ieca.com (mva-aa-044.capu.net [207.226.159.44]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA20102; Thu, 30 Nov 2000 10:20:56 -0500 Message-ID: <3A267053.C3273DB7@ieca.com> Date: Thu, 30 Nov 2000 10:20:51 -0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: ietf-smime@imc.org Subject: Re: RSA vs. DSA MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, Did I mention that sticking my arm into hornets nests is one of my favorite hobbies. ;-) This nest look good and ripe... Bob Jueneman wrote: > Chris, I believe these points are important, and perhaps more important than the particular issues at hand. So please allow me to wax philosophical. > > As a consumer, all things being equal, I like products that support lots of interoperability modes too. Beer, champagne, hot dogs, filet mignon, ice cream, apple pie, floor wax and desert topping -- they're all great, at least if you can afford them. > > But as a vendor, I am increasingly concerned about the amount of feature creep that we are seeing every day in both the PKIX and SMIME groups, apparently almost unconstrained by business requirements. We need interoperability, and that should not mean lowest common denominator, but it also shouldn't mean being all things to all men. > I think that most of the "feature creep" to which you refer is in the realm of options. There is still a fairly small core of S/MIME features that are MUSTs, and nearly all of them have some core interoperability reason. > > Now allow me to (gently, I hope) take issue with some of your other statements: > > > > * The implementation cost of DSA/D-H/3DES was acceptable when RSA was patented, but now that some of us have actually built/tested this the cost > >has gone up into the "too high" range. > > I would disagree. The cost of the RSA license was minimal relative to other development costs, and the RSA algorithm was effectively all there was in terms of deployed PKI infrastructure. The fact that DSA and D-H were labeled MUST was chalked up to IETF politics, and completely ignored by the vendor community as not being worth the implementation cost in terms of revenue return. Granted, it didn't meet some of the expressed desires of the US Government, but the USG has always had a much bigger appetite than budget. (Remember Jovial? Ada? C2 by '92?) Money talks, and everything else walks. They imposed requirements, but those requirements didn't stick when it came to real procurements. > Okay, but you're arguing against something that I'm not saying. I'm not saying that anything should be MUST (in fact, I think the reverse should be the case). I am also NOT saying that we should implement these algorithms because the government says so (like Ada, etc.). What I'm saying is that two years ago WE said is was good enough, cheap enough, etc. Now suddenly it isn't. What gives. I'm trying to point out some intellectual disingenuousness, not arguing for an end state. > > > > * Specifying a single MUST algorithm suite was sufficient to make S/MIME algorithm independent, but actually requiring two algorithms suites will cost too > >much. If we've really achieved algorithm independence in the sense that Dave Kemp suggests, this should be a debate about a relatively small math module. > > No, again I disagree. The math module isn't the problem. As a BSAFE licensee, we already have all of the math modules we would need. The real issue is all of the multitudinous GUI screens that have to be developed to allow the user to choose this, that or the other algorithm within S/MIME, and then the same set of choices in any PKI products, and then testing all of these options in every conceivable combination, not just within a given product but in combination with all of the other leading e-mail packages, plus the various PKI services and toolkits as well. those costs dwarf the cost of the math module by a couple of orders of magnitude. > This seems a little overstated. As a developer, surely you have the latitude to design your GUIs the way you want. That doesn't stop you from supporting whatever algorithms you want, or auto-selecting based on the 'SMIMECapabilities'. > > > * We have an 'SMIMECapabilities' attribute for which support is MUST, but some implementations ignore it so we have to use the lowest common > >denominator to force interoperability. What make anybody think a MUST on an algorithm choice would be taken any more seriously? > > Two issues. As I recall, the SMIMECapabilities is a MAY, not a MUST, although I'll stand corrected if I'm wrong. And as I say, and Peter Gutmann said more succinctly, MUST matters if and only if the vendor was inclined to implement that option anyway. It might be sufficient to push someone over the fence who was already 49% there, but not much more. Standards compliance doesn't pay the rent -- customers do. > The 'SMIMECapabilities' attribute is a MUST on reception, and a SHOULD on origination. On your second point, you have zeroed in on the point of my third bullet admirably. If the MUST doesn't mean much, why are we debating it like it's a meaningful decision? > > > > I don't think I actually have an opinion on this issue myself. I'm of the mind set to mandate nothing and let Darwin decide. However, I find the seeming > >illogic of these collective opinions very troubling. It leads me to think that we're not getting to the REAL reasoning behind this move. > > > > I think Blake was closest to this in stating that there has been no customer demand for DSA. Is this the REAL reason to dump DSA? Are customers > >demanding RSA be used? Do customers express demand for any algorithms, or do they just want it to be "secure"? Are we just drifting to the path of least > >resistance? > > Customers don't demand or specify algorithms. They just want it to be secure, and trust that the vendor will figure out what that means. What they do insist on, however, is that the product work well with the existing infrastructure in order to reduce their total overall cost of ownership. The more sophisticated customers realize that adding more and more features that they never use significantly increases that TCO, so overburdening a product with unnecessary features causes a significant backlash. Increased cost of development with decreased sales. What a concept! > However, by this logic nothing ever improves. I'm not knowledgable enough to say whether DSA/D-H is an *improvement* over RSA, or just another choice. Nevertheless, I think this evaluation should be a factor. Somebody else asked the question too. (?) Is DSA/D-H better? If not, then its okay to stick with what's out there. If is it, then we've got to decide if it's better enough to be worth upgrading the infrastructure. I have not even heard this point raised yet. Why not? All the best, Chris sends... From owner-ietf-smime Thu Nov 30 15:43:05 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA24111 for ietf-smime-bks; Thu, 30 Nov 2000 15:43:05 -0800 (PST) Received: from dns.wsbx.com ([202.99.11.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24107 for ; Thu, 30 Nov 2000 15:43:04 -0800 (PST) Date: Thu, 30 Nov 2000 15:43:04 -0800 (PST) From: Younger@bdsm.at Message-Id: <200011302343.PAA24107@ns.secondary.com> Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by dns.wsbx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id X703J4LZ; Fri, 1 Dec 2000 07:47:20 +0800 To: Younger@bdsm.at Subject: REVERSE the AGING PROCESS 10-20 Years! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express payments. Money Orders are accepted only by Postal Mail. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International shipping, please add $35 for any size order [ Total cost including shipping & handling, 1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ] Foreign checks are not accepted. Credit cards & international money orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: Lion Sciences National 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements. From owner-ietf-smime Fri Dec 1 04:48:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA21182 for ietf-smime-bks; Fri, 1 Dec 2000 04:48:10 -0800 (PST) Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA21175 for ; Fri, 1 Dec 2000 04:48:08 -0800 (PST) Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Fri, 1 Dec 2000 12:49:17 +0000 Received: from ahmed (AHMED.sse.ie [193.120.32.223]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id MAA01984 for ; Fri, 1 Dec 2000 12:49:16 GMT From: "Ahmed Bhamjee" To: Subject: SMIME Freeware Library v1.8 Date: Fri, 1 Dec 2000 12:48:21 -0000 Message-ID: <000001c05b95$02aef8d0$df2078c1@sse.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C05B95.02AEF8D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200011301057.FAA28262@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C05B95.02AEF8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Could someone please point me to a url where I can find the SMIME Freeware Library v1.8. I have been trying the following url with no success: http://www.armadillo.huntsville.al.us/software/smime Thanks Ahmed ------=_NextPart_000_0001_01C05B95.02AEF8D0 Content-Type: application/octet-stream; name="http---www.armadillo.huntsville.al.us-software-smime.url" Content-Disposition: attachment; filename="http---www.armadillo.huntsville.al.us-software-smime.url" Content-Transfer-Encoding: 7bit [InternetShortcut] URL=http://www.armadillo.huntsville.al.us/software/smime Modified=2038EDA8945BC0019D ------=_NextPart_000_0001_01C05B95.02AEF8D0-- From owner-ietf-smime Fri Dec 1 05:57:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA24681 for ietf-smime-bks; Fri, 1 Dec 2000 05:57:29 -0800 (PST) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24676 for ; Fri, 1 Dec 2000 05:57:27 -0800 (PST) Received: from wwilliams2 (dhcp058-134.genuity.com [171.78.58.134]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id JAA20456; Fri, 1 Dec 2000 09:00:44 -0500 (EST) From: "Walter Williams" To: "Ahmed Bhamjee" , Subject: RE: SMIME Freeware Library v1.8 Date: Fri, 1 Dec 2000 08:54:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000001c05b95$02aef8d0$df2078c1@sse.ie> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: While that server appears to be down, you might want to look at http://www.mozilla.org/projects/security/pki/nss/smime/ as an alternative. This is a S/MIME toolkit developed by what used to be Netscape. Walt Williams Genuity > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Ahmed Bhamjee > Sent: Friday, December 01, 2000 7:48 AM > To: ietf-smime@imc.org > Subject: SMIME Freeware Library v1.8 > > > Could someone please point me to a url where I can find the SMIME Freeware > Library v1.8. I have been trying the following url with no success: > > http://www.armadillo.huntsville.al.us/software/smime > > Thanks > Ahmed > From owner-ietf-smime Sun Dec 3 15:35:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA08588 for ietf-smime-bks; Sun, 3 Dec 2000 15:35:16 -0800 (PST) Received: from nt40srv.sudsistemi.it ([138.66.150.18]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA08545 for ; Sun, 3 Dec 2000 15:33:46 -0800 (PST) From: bn1bn2@yahoo.com Received: from wk3F17b6r (unverified [63.28.123.13]) by nt40srv.sudsistemi.it (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 04 Dec 2000 00:31:14 +0100 DATE: 03 Dec 00 3:38:51 PM Message-ID: SUBJECT: Holiday Special: Don't miss the savings! Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hurry!!! Time is running out. Thinking of getting a laptop computer for the holidays, or any occasions... Brand new name brand notebooks at up to 35% savings, compare around than call us 1-800-644-9584. We have thousands Notebook PC, PDAs, Digital Cameras, Parts and Accessories in stock for the holiday, anything you need, we can get you the lower prices. C o m p a q ================================================== Compaq Armada M700 $2199 Intel PIII 650 MHz, 128MB, 12.0GB, 14.1in TFT, 24X CD-ROM, 56 Kbps, 10/100 Ethernet Card, Windows NT 4.0 Compaq Presario 1200-XL125 $1379 AMD K6-2 533 MHz, 64MB , 6.0GB, 13.3in TFT, 8X DVD-ROM, 56Kbps , WIN98se Compaq Presario 1200-XL300 $1095 Intel Celeron 600 MHz, 64MB, 6.0GB, 13in HPA, 24X CD-ROM, 56K , Windows ME Compaq Presario 1200-XL325 $1499 Intel PIII 650 MHz, 64MB, 6.0GB, 13.3in TFT, 8X DVD-ROM, 56K , Windows ME Compaq Presario 1700-XL360 $1799 Intel PIII 600 MHz, 64MB, 10.0GB, 14.1in TFT, 8X DVD-ROM, 56K , Windows ME H P ==================================================== HP Omni Book 6000 $3499 Intel PIII 850MHz , 128 MB , 20GB, 15.1in TFT, 8X DVD-ROM, 56Kbps, Windows 2000 HP Pavilion N5150 $1499 Intel PIII 600 MHz, 64MB, 10.0GB , 13.3in TFT, 8X DVD-ROM, 56Kbps, Windows Millennium Edition HP Pavilion N5170 $1599 Intel PIII 600 MHz , 64MB, 7.0GB , 14.1in TFT, 8X DVD-ROM, 56Kbps, 10/100 Ethernet, Windows Millennium Edition HP Pavilion N5195 $2199 Intel PIII 700 MHz , 128MB , 20.0GB , 15.1in TFT, 8X DVD-ROM, 56Kbps, 10/100 Ethernet, Windows Millennium Edition S O N Y ==================================================== Sony VAIO PCG-F580 Notebook $2099 Intel PIII 650 MHz, 64MB, 12.0GB, 15.0in TFT, 8X DVD-ROM, 56K, Windows 98se Sony VAIO PCG-F650 Notebook $1889 Intel PIII 600 MHz, 64MB, 12.0GB, 14.1in TFT, 8X DVD-ROM, 56Kbps, Windows ME For more info or to place an order call: 1-800-644-9584 To Visit Our Site http://www.laptopland.com to find out more detail This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301)."Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to be removed. INSTRUCTIONS- click here mailto:member9288@computerassociation.com?subject=removelist134 to be removed. From owner-ietf-smime Mon Dec 4 10:25:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12570 for ietf-smime-bks; Mon, 4 Dec 2000 10:25:55 -0800 (PST) Received: from sparta.com (IDENT:root@M5.sparta.com [157.185.61.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12565 for ; Mon, 4 Dec 2000 10:25:53 -0800 (PST) Received: from huntsville.sparta.com (huntsville.sparta.com [157.185.4.13]) by sparta.com (8.9.3/8.9.3) with ESMTP id MAA11421; Mon, 4 Dec 2000 12:27:48 -0600 Received: from williamspc4 (williamspc4 [157.185.4.50]) by huntsville.sparta.com (8.9.3+Sun/8.8.5) with SMTP id MAA17618; Mon, 4 Dec 2000 12:27:46 -0600 (CST) Reply-To: From: "Eugene C. \(Gene\) Williams" To: "Ahmed Bhamjee" , "Ietf-Smime" Subject: RE: SMIME Freeware Library v1.8 Date: Mon, 4 Dec 2000 12:38:18 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001C_01C05DEF.147EE000" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000001c05b95$02aef8d0$df2078c1@sse.ie> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C05DEF.147EE000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ahmed, See attached message from John Pawling...John has the service become available yet? v.r. Gene -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Ahmed Bhamjee Sent: Friday, December 01, 2000 6:48 AM To: ietf-smime@imc.org Subject: SMIME Freeware Library v1.8 Could someone please point me to a url where I can find the SMIME Freeware Library v1.8. I have been trying the following url with no success: http://www.armadillo.huntsville.al.us/software/smime Thanks Ahmed ------=_NextPart_000_001C_01C05DEF.147EE000 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Reply-To: From: "Pawling, John" Sender: To: "Multiple recipients of list" Subject: SFL/CML/ACL/Enhanced SNACC Freeware Availability Date: Tue, 21 Nov 2000 10:16:42 -0600 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B18C7@wfhqex01.wangfed.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Internet Mail Service (5.5.2650.21) X-UIDL: 16927760697143d93e9a32f6c1124357 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-To: "Pawling, John" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas All, The freeware Certificate Management Library (CML), S/MIME Freeware Library (SFL), Access Control Library (ACL) and Enhanced SNACC ASN.1 freeware are no longer available from the web site. They will be available on the Getronics Government Solutions web site by 1 December 2000. I will inform everyone as soon as they are available. They will continue to be freely available to everyone. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== ------=_NextPart_000_001C_01C05DEF.147EE000-- From owner-ietf-smime Mon Dec 4 12:05:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA20345 for ietf-smime-bks; Mon, 4 Dec 2000 12:05:03 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20339 for ; Mon, 4 Dec 2000 12:05:02 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 15:06:29 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B19BD@wfhqex01.wangfed.com> From: "Pawling, John" To: "'williams@huntsville.sparta.com'" , Ahmed Bhamjee , Ietf-Smime Subject: RE: SMIME Freeware Library v1.8 Date: Mon, 4 Dec 2000 15:06:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, The freeware Certificate Management Library (CML), S/MIME Freeware Library (SFL), Access Control Library (ACL) and Enhanced SNACC ASN.1 freeware will be available on the Getronics Government Solutions web site on 6 December 2000. I will inform everyone as soon as they are available. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-ietf-smime Tue Dec 5 11:19:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13451 for ietf-smime-bks; Tue, 5 Dec 2000 11:19:07 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13440; Tue, 5 Dec 2000 11:19:05 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 14:20:35 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B19DA@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: SFL/CML/ACL/SNACC Freeware Available *NEW CML RELEASE* Date: Tue, 5 Dec 2000 14:20:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, The freeware Certificate Management Library (CML), S/MIME Freeware Library (SFL), Access Control Library (ACL), Enhanced SNACC ASN.1 freeware and Cryptographic Token Interface Libraries (CTIL) developed by Getronics Government Solutions are now available from the following web pages: SFL and CTILs: CML: ACL: Enhanced SNACC ASN.1 Freeware: **NEW CML RELEASE**: The CML files available from are a new release. The v1.81 CML release fixes bugs in the v1.8 CML as documented in the v1.8 CML Problem Report file. With the exception of the CML files, there are no significant differences between the files available from the Getronics Government Solutions web pages and those that were formerly available from the Fortezza Developers Web Site . We welcome all feedback regarding these freeware security libraries. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-ietf-smime Tue Dec 5 13:20:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA23836 for ietf-smime-bks; Tue, 5 Dec 2000 13:20:31 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23828 for ; Tue, 5 Dec 2000 13:20:30 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA26322; Tue, 5 Dec 2000 13:21:53 -0800 (PST) Message-Id: <5.0.1.4.2.20001205144808.0299f428@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 05 Dec 2000 14:55:31 -0500 To: Graeme Lunt From: Russ Housley Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt Cc: ietf-smime@imc.org, "'j.onions@nexor.co.uk'" In-Reply-To: <3130909C0878D4118010006008517A7C02112C@swordfish.nexor.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Graeme: The id-data content type should NOT be used to identify a CMS content in an X.400 envelope. I assigned the id-ct-contentInfo OID for this purpose. I am trying to make id-data a useful identifier. If we use it for too many things, it will not help anyone determine how to process a content. Russ At 10:41 AM 11/16/2000 +0000, Graeme Lunt wrote: >Russ, > > > The CMS contentInfo uses id-data when the content is expected to be > > MIME. This choice is for historical reasons (S/MIME v2 did > > it that way). > > > > I think that the authors are trying to avoid a layer of MIME > > encapsulation. > >Yes - I can see that you would want to avoid this. > > > Did I miss something? > >My comment was a little different. > >What is being proposed is that the OID id-data must be used for the >X.400 content type when the CMS object is covered by an outer MIME >wrapper. > >However, a more generic option is to use an OID (say "id-mime") for >the X.400 content type that represents MIME. >Using this content type I could still carry my MIME wrapped CMS object, >but I could also carry other arbitray MIME objects. For example, I >could carry multipart/signed with this method. > >In fact, thinking about it a little more, does the draft as it stands >actually allow me to do this? If I use id-data as the content-type, >MUST the content be a MIME wrapped CMS object? Could it just be arbitrary >MIME? > >This would certainly be a useful feature. > >Graeme From owner-ietf-smime Wed Dec 6 20:58:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23708 for ietf-smime-bks; Wed, 6 Dec 2000 20:58:48 -0800 (PST) Received: from bsd.gymparnr.sk (bsd.gymparnr.sk [195.168.176.67]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA23671 for ; Wed, 6 Dec 2000 20:58:44 -0800 (PST) From: hjghjgjh@yahoo.com Received: (qmail 16826 invoked from network); 6 Dec 2000 00:18:39 -0000 Received: from 1cust62.tnt1.los-angeles.ca.da.uu.net (HELO qYo7NPC3Z?) (63.57.183.62) by bsd.gymparnr.sk with SMTP; 6 Dec 2000 00:18:39 -0000 DATE: 05 Dec 00 4:38:15 PM Message-ID: <674UGKz14zV7En09R14> SUBJECT: 1+1=2 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Internet's Finest and Most Reliable Bulk Email Provider! Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use. We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics. Call us for a free consultation at (323)- 851- 8386 [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value! BULK EMAIL PRICES 500,000........................$375 750,000........................$562 1,200,000........................$720 1,600,000.................. ...$960 3,000,000......................$1,500 3,000,000+ ...................PLEASE CALL FOR A QUOTE Resellers welcome. We accept Visa, MasterCard and check by FAX. DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!! Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ietf-smime Thu Dec 7 02:43:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA09005 for ietf-smime-bks; Thu, 7 Dec 2000 02:43:57 -0800 (PST) Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08998 for ; Thu, 7 Dec 2000 02:43:56 -0800 (PST) Received: from scherbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id LAA13614 for ; Thu, 7 Dec 2000 11:34:33 +0100 Message-Id: <200012071034.LAA13614@rom.antech.de> From: "Stefan Kelm" Organization: Secorvo Security Consulting GmbH To: ietf-smime@imc.org Date: Thu, 7 Dec 2000 11:45:56 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: v2/v3 comparison document? Reply-to: kelm@secorvo.de In-reply-to: <5.0.1.4.2.20001205144808.0299f428@mail.spyrus.com> References: <3130909C0878D4118010006008517A7C02112C@swordfish.nexor.co. uk> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I'm looking for some kind of roadmap of high-level document that compares S/MIME v2 against v3. Is such a text available anywhere? Any input is highly appreciated. Cheers, Stefan. ------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm@secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B From owner-ietf-smime Thu Dec 7 15:05:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA03763 for ietf-smime-bks; Thu, 7 Dec 2000 15:05:39 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03758; Thu, 7 Dec 2000 15:05:36 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA15272; Fri, 8 Dec 2000 12:07:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97623046120024>; Fri, 8 Dec 2000 12:07:41 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, ietf-smime@imc.org Subject: Semi-annual reminder: dumpasn1 utility available Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 8 Dec 2000 12:07:41 (NZDT) Message-ID: <97623046120024@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a semi-annual reminder to people about dumpasn1, which picks apart ASN.1 data and displays it in human-readable form. I do actually update this every now and then, so it's worth checking every few months for new copies. Recent (within the last 6-12 months) features include automatic detection of stuff encapsulated inside bit/octet strings (no more -o or -b options), detection of encapsulated text strings disguised as something else, the ability to display text alongside a hex dump of data, an attempt at displaying BMPStrings under Windows (which for console apps doesn't actually work anything like what the docs would have you believe, if anyone can get it to display non 8859-1 characters let me know), and an indication of which bit is set if you've got a large string of zero bits with a single 1 bit at the start (this was motivated by the need to pick apart CMP error codes). Available as usual from http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c|.cfg} for the source code and config file. Peter. From owner-ietf-smime Sat Dec 9 04:49:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA07180 for ietf-smime-bks; Sat, 9 Dec 2000 04:49:07 -0800 (PST) Received: from yengec (kasirga.tsk.mil.tr [212.50.36.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA07173 for ; Sat, 9 Dec 2000 04:49:03 -0800 (PST) Received: from yengec (192.168.1.1 [192.168.1.1]) by tufan.tsk.mil.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XAQ70VRT; Sat, 9 Dec 2000 14:49:59 +0200 Message-ID: <007801c061e0$a7aee740$4c2b1d3e@erdal> From: "Erdal YILDIZ" To: Subject: looking for introductory s/mime docs? Date: Sat, 9 Dec 2000 15:04:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C061F1.664E6440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C061F1.664E6440 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Hi All; I am looking for some high level documants about s/mime. I am very new = in taht area and the docs I look for must be in the beginners level. = What is s/mime? The initiatives for it? Historical story of it? Etc. If someone help me I would be really very appreciated. Thanks in advance Erdal ------=_NextPart_000_0073_01C061F1.664E6440 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
Hi All;
I am looking for some high level = documants about=20 s/mime. I am very new in taht area and the docs I look for  must be = in the=20 beginners level. What is s/mime? The initiatives for it? Historical = story of it?=20 Etc.
If someone help me I would be really = very=20 appreciated.
Thanks in advance
Erdal
------=_NextPart_000_0073_01C061F1.664E6440-- From owner-ietf-smime Sat Dec 9 09:13:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17773 for ietf-smime-bks; Sat, 9 Dec 2000 09:13:27 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17735; Sat, 9 Dec 2000 09:12:42 -0800 (PST) Message-Id: <200012091712.JAA17735@ns.secondary.com> From: Mail Sender To: ietf-rip-request@baynetworks.com CC: ietf-run@mailbag.cps.intel.com, ietf-sacred@imc.org, ietf-sacred-request@imc.org, ietf-secretariat@ietf.org, ietf-smime@imc.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-smime Sat Dec 9 12:00:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21201 for ietf-smime-bks; Sat, 9 Dec 2000 12:00:41 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21197 for ; Sat, 9 Dec 2000 12:00:39 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA23076; Sun, 10 Dec 2000 09:02:46 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97639216626966>; Sun, 10 Dec 2000 09:02:46 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: eyildiz@tsk.mil.tr, ietf-smime@imc.org Subject: Re: looking for introductory s/mime docs? Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sun, 10 Dec 2000 09:02:46 (NZDT) Message-ID: <97639216626966@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Erdal YILDIZ" >I am looking for some high level documants about s/mime. I am very new in taht >area and the docs I look for must be in the beginners level. What is s/mime? >The initiatives for it? Historical story of it? Etc. You could look at part 3 of my crypto tutorial, http://www.cs.auckland.ac.nz/~pgut001/tutorial/, which covers among other things "email security mechanisms, PEM, the PEM CA model, PGP, PGP keys and the PGP trust model, MOSS, PGP/MIME, S/MIME and CMS, MSP" at a reasonably easy level. The historical background and other information is in there as well. Peter. From owner-ietf-smime Mon Dec 11 06:11:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA24978 for ietf-smime-bks; Mon, 11 Dec 2000 06:11:29 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24969 for ; Mon, 11 Dec 2000 06:11:25 -0800 (PST) Received: by sentry.gw.tislabs.com; id JAA29805; Mon, 11 Dec 2000 09:16:32 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma029741; Mon, 11 Dec 00 09:15:53 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA12317 for ietf-smime@imc.org; Mon, 11 Dec 2000 09:12:11 -0500 (EST) Date: Mon, 11 Dec 2000 09:12:11 -0500 (EST) From: "David M. Balenson" Message-Id: <200012111412.JAA12317@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-smime Tue Dec 12 03:16:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01128 for ietf-smime-bks; Tue, 12 Dec 2000 03:16:50 -0800 (PST) Received: from mail1.sse.ie (s193-120-32-20.sse.ie [193.120.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01123 for ; Tue, 12 Dec 2000 03:16:48 -0800 (PST) Received: from ahmed (AHMED.sse.ie [193.120.32.223]) by mail1.sse.ie (8.11.1/8.11.1) with SMTP id eBCBIpr23866 for ; Tue, 12 Dec 2000 11:18:52 GMT From: "Ahmed Bhamjee" To: Subject: UKM size in the SMIME Freeware Library v1.8 Date: Tue, 12 Dec 2000 11:18:16 -0000 Message-ID: <000101c0642d$3a55a090$df2078c1@sse.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <000001c05b95$02aef8d0$df2078c1@sse.ie> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have been testing our product with the latest SFL version. More specifically, I have performed tests using the Diffie-Hellman key agreement method. From the RFC (2631), the size of partyAInfo contained in the OtherInfo sequence must be 512 bits in size. However, the SFL produces keying material with partyAInfo set to 128 bytes. Should this not be 64 bytes? Perhaps I am missing something. Thanks Ahmed From owner-ietf-smime Wed Dec 13 03:22:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA08598 for ietf-smime-bks; Wed, 13 Dec 2000 03:22:08 -0800 (PST) Received: from gw.capgemini.fr (gw.capgemini.fr [194.3.247.254]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08591 for ; Wed, 13 Dec 2000 03:22:06 -0800 (PST) Received: from prenoms.capgemini.fr (capmail.capgemini.fr [194.2.91.200]) by gw.capgemini.fr (8.9.3/8.9.1) with ESMTP id MAA24051; Wed, 13 Dec 2000 12:24:13 +0100 (MET) Received: from prenoms.capgemini.fr (localhost [127.0.0.1]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id MAA21639; Wed, 13 Dec 2000 12:24:15 +0100 (MET) Received: from bboutelo ([195.124.153.97]) by prenoms.capgemini.fr (8.9.3/8.9.3) with SMTP id MAA21537; Wed, 13 Dec 2000 12:24:13 +0100 (MET) Message-ID: <00d501c064f7$38e1dd80$02000000@bboutelo> From: "Bertrand BOUTELOUP" To: Subject: Proposed amendment to the Compressed data Content type for S/MIME Date: Wed, 13 Dec 2000 12:24:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01C064FF.97B2F620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C064FF.97B2F620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here are some amendments on the following draft: > Title : Compressed Data Content Type for S/MIME=20 Can we add as an optional field the "SizeUncomp" field in the The = compressed-data type. SizeUncomp will be the size of non compressed = data. Best regards. Bertrand BOUTELOUP ------=_NextPart_000_00CE_01C064FF.97B2F620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

Here are some amendments on the following = draft:
>=20 Title : Compressed=20 Data Content Type for S/MIME
 
Can we add as an optional field the = "SizeUncomp" field in the The compressed-data type. = SizeUncomp will=20 be the size of non compressed data.
Best=20 regards.
 
Bertrand BOUTELOUP
------=_NextPart_000_00CE_01C064FF.97B2F620-- From owner-ietf-smime Wed Dec 13 09:16:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05656 for ietf-smime-bks; Wed, 13 Dec 2000 09:16:35 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05650 for ; Wed, 13 Dec 2000 09:16:34 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.71.200.tx.verio.net [207.137.71.200]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA00313; Wed, 13 Dec 2000 09:18:36 -0800 (PST) Message-Id: <5.0.1.4.2.20001212123236.028d96a0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 12 Dec 2000 12:36:27 -0500 To: "Ahmed Bhamjee" From: Russ Housley Subject: Re: UKM size in the SMIME Freeware Library v1.8 Cc: In-Reply-To: <000101c0642d$3a55a090$df2078c1@sse.ie> References: <000001c05b95$02aef8d0$df2078c1@sse.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RFC 2631 says: partyAInfo is a random string provided by the sender. In CMS, it is provided as a parameter in the UserKeyingMaterial field (encoded as an OCTET STRING). If provided, partyAInfo MUST contain 512 bits. I do not see any ambiguity here... Russ At 11:18 AM 12/12/2000 +0000, Ahmed Bhamjee wrote: >I have been testing our product with the latest SFL version. More >specifically, I have performed tests using the Diffie-Hellman key agreement >method. From the RFC (2631), the size of partyAInfo contained in the >OtherInfo sequence must be 512