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