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 b