From owner-ietf-smime@imc.org Mon Feb 7 10:07:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11989 for ; Mon, 7 Feb 2000 10:07:38 -0500 (EST) 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: Content-Transfer-Encoding: 7bit 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@imc.org Mon Feb 7 12:40:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16482 for ; Mon, 7 Feb 2000 12:40:48 -0500 (EST) 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: Content-Transfer-Encoding: 7bit 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@imc.org Mon Feb 7 13:54:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18961 for ; Mon, 7 Feb 2000 13:54:43 -0500 (EST) 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@imc.org Mon Feb 7 14:14:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19369 for ; Mon, 7 Feb 2000 14:14:23 -0500 (EST) 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: Content-Transfer-Encoding: 8BIT 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@imc.org Mon Feb 7 14:17:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19429 for ; Mon, 7 Feb 2000 14:17:48 -0500 (EST) 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@imc.org Mon Feb 7 15:17:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20734 for ; Mon, 7 Feb 2000 15:17:30 -0500 (EST) 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@imc.org Mon Feb 7 16:16:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21951 for ; Mon, 7 Feb 2000 16:16:10 -0500 (EST) 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@imc.org Mon Feb 7 16:20:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22031 for ; Mon, 7 Feb 2000 16:20:50 -0500 (EST) 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@imc.org Tue Feb 8 05:23:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13112 for ; Tue, 8 Feb 2000 05:23:25 -0500 (EST) 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: Content-Transfer-Encoding: 7bit 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@imc.org Tue Feb 8 11:23:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00019 for ; Tue, 8 Feb 2000 11:23:19 -0500 (EST) 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@imc.org Wed Feb 9 10:21:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07939 for ; Wed, 9 Feb 2000 10:21:24 -0500 (EST) 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@imc.org Wed Feb 9 12:12:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11061 for ; Wed, 9 Feb 2000 12:12:52 -0500 (EST) 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@imc.org Wed Feb 9 12:33:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12023 for ; Wed, 9 Feb 2000 12:33:28 -0500 (EST) 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: Content-Transfer-Encoding: 7bit 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@imc.org Wed Feb 9 12:57:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13203 for ; Wed, 9 Feb 2000 12:57:53 -0500 (EST) 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@imc.org Wed Feb 9 15:20:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21533 for ; Wed, 9 Feb 2000 15:20:29 -0500 (EST) 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@imc.org Wed Feb 9 17:32:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25999 for ; Wed, 9 Feb 2000 17:32:11 -0500 (EST) 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@imc.org Wed Feb 9 19:53:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28636 for ; Wed, 9 Feb 2000 19:53:34 -0500 (EST) 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@imc.org Wed Feb 9 22:40:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02421 for ; Wed, 9 Feb 2000 22:40:14 -0500 (EST) 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@imc.org Thu Feb 10 13:01:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05996 for ; Thu, 10 Feb 2000 13:01:54 -0500 (EST) 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@imc.org Thu Feb 10 13:04:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06080 for ; Thu, 10 Feb 2000 13:04:58 -0500 (EST) 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@imc.org Fri Feb 11 13:02:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15998 for ; Fri, 11 Feb 2000 13:02:17 -0500 (EST) 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@imc.org Mon Feb 14 17:44:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25800 for ; Mon, 14 Feb 2000 17:44:34 -0500 (EST) 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@imc.org Mon Feb 14 18:54:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26779 for ; Mon, 14 Feb 2000 18:54:15 -0500 (EST) 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: Content-Transfer-Encoding: 8bit This has been a fascinating discussion, in part because of the multi-dimensional aspects to the problem. Let me see if I can summarize some of the different points of view: The first issue raised was one of privacy, and in particular the possibility of spam. This reminds me of two lessons I learned so time ago, rather forcefully, with regard to this space. Back in the PEM days, I was concentrating on the question of how to ensure the legal sufficiency of a digital signature to assure nonrepudiation, and I was suggesting that full name, verified address, and perhaps social security number or driver's license number be included in the certificate. John Gilmore brought me up short by pointing out that we were supposed to be talking about privacy ENHANCED mail. Point taken -- some of this stuff needs to be optional. Then a few years later, I was trying to solve the problem of uniquely identifying someone in a directory, given the presumption at the time that multiple directory service providers (e.g., telcos) might exist and might have overlapping geopolitical boundaries. The answer to this problem, it seemed to me, was to include sufficient disambiguating information, such as street address, assuming that there wouldn't be two people with the same name in the same household. Sharon Boyen gave me another much needed lesson in political correctness by pointing out that many women, in particular, weren't about to list their residence address in a public directory, and many wouldn't even list their given names, preferring to be listed as "M. Smith". Point taken again. If necessary, include meaningless qualifiers such as employeeID for uniqueness. So these are legitimate issues, and I suppose that spam mail is the virtual equivalent of stalking. So I accept the position that says that an e-mail address should not be required, either in the DN or the subjectAltName, although it may be desirable. This bears on the second issue, which I raised at the November meeting, where I pointed out that it was all too easy to manipulate the From address in an e-mail so that the addr-spec portion would match the e-mail address in the certificate, and yet the user-friendly portion of the name could be completely bogus and seriously misleading. I now think that I agree with David Kemp -- this is primarily a man/machine interface issue. In other words, the conventional paradigm of presenting the From address as the primary identification of the sender is WRONG in the case of a digitally signed message, and especially so considering how easily it can be forged or manipulated. Instead, in the case of a signed message the From address should be viewed as secondary, and the certificate contents the primary information. The "contents": in this case should probably include the DN and the subjectAltName, even if it takes an additional line of the GUI display. Of course, we have to face the fact that NEITHER the DN nor the RFC822 address may be particularly relevant or informative. In the case of the DN, at least from the perspective of someone who works for a directory company, the DN is probably going to be whatever it is today, not withstanding the fact that directories today are primary set up for the convenience of the system administrator, and secondly for the benefit of users within the organization, and thirdly if at all for the benefit of users outside of the organization. In my case, for example, my directory name is bjueneman.nsrd.prv.novell (note the "backwards" presentation order), or o=Novell, ou=prv, ou=nsrd, cn=bjueneman. Hardly very helpful to someone on the outside, and certainly not what I would like, but unlikely to change any time soon. Of course, bjueneman@novell.com isn't very helpful either, but better than graybeard123@aol.com. (Public CAs may not have this problem, as they would tend to put "meaningful" names in a directory.) So the ugly fact of the matter is that both DNs and RFC822 names are really the result of legacy systems, and are unlikely to change or to be very helpful. So neither is really satisfactory. My preferred solution? Use an _additional_ subjectAltName to convey the person's "real" name, suitably qualified if desired. And leave the directory DN to the directory administrators, and the RFC822 name to e-mail administrators. Render unto Caesar .... Then in the message display, present the subjectAltName containing a commonName format as primary (if present), the RFC822 address as secondary (if present), and the DN as supplemental information (if present). IN order to assure at least some semblance of uniqueness, either the RFC822 name or the DN MUST be present, and the "real" commonName SHOULD be present. The banner portion of a signed message from me would then be properly displayed as: Signer: Robert R. (Bob) Jueneman [bjueneman@novell.com] [o=Novell, ou=prv, ou=nsrd, cn=bjueneman] The From address, i.e., what the RFC822 From address itself was, would not normally be displayed, except by viewing the message in RFC822 format. I believe that the combination of these three different name forms will be sufficient to adequately disambiguate the sender of a message, and to prevent all sorts of mischief and possible accidents. If this is the display format, I don't care that much about what the name matching rules are, or even whether name matching is done at all. So far, name matching seems to be causing more problems than it solves. Comments? Bob From owner-ietf-smime@imc.org Mon Feb 14 19:33:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27633 for ; Mon, 14 Feb 2000 19:33:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25435 for ietf-smime-bks; Mon, 14 Feb 2000 15:56:30 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25431 for ; Mon, 14 Feb 2000 15:56:28 -0800 (PST) Message-Id: <4.2.1.20000214155658.03fabec0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 14 Feb 2000 16:01:05 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Problem for public CAs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Tue Feb 15 06:04:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21862 for ; Tue, 15 Feb 2000 06:04:02 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA16729 for ietf-smime-bks; Tue, 15 Feb 2000 02:25:31 -0800 (PST) Received: from citicorp.com (mango2-a.citicorp.com [192.193.196.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16725 for ; Tue, 15 Feb 2000 02:25:29 -0800 (PST) From: bartley.o'malley@citicorp.com Received: from myrtle2.citicorp.com (imta.citicorp.com [192.193.195.189]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12103 for ; Tue, 15 Feb 2000 05:26:17 -0500 (EST) Received: from x400prod2.cgin.us-md.citicorp.com (root@wtprod2.cgin.us-md.citicorp.com [163.39.141.206]) by myrtle2.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12025 for ; Tue, 15 Feb 2000 05:29:21 -0500 (EST) Received: from mercury.lew.gb.citicorp.com (root@mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA03863 Tue, 15 Feb 2000 05:29:20 -0500 (EST) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02037 for ietf-smime@imc.org; Tue, 15 Feb 2000 10:29:17 GMT X-OpenMail-Hops: 1 Date: Tue, 15 Feb 2000 10:29:11 +0000 Message-Id: Subject: RE: Re: Problem for public CAs MIME-Version: 1.0 TO: ietf-smime@imc.org Content-Type: multipart/mixed; boundary="openmail-part-10d68c22-00000001" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --openmail-part-10d68c22-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium --openmail-part-10d68c22-00000001 Content-Type: application/ms-tnef; name="WINMAIL.DAT" Content-Disposition: attachment; filename="WINMAIL.DAT" Content-Transfer-Encoding: base64 eJ8+IqQ+AQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABAB8AAABSRTogUmU6IFByb2JsZW0gZm9y IHB1YmxpYyBDQXMA8AkBA5AGABAAAAABAAAAQAA5ADBk+lKfd78BMAQBA5AGABQAAAABAAAA HgBCEAEAAAABAAAAAAAAAHMAAQOQBgAoAAAAAQAAAAIBcQABAAAAFgAAAAG/d59S2Kok4d/j jhHTsPgAAfrU+5YAAHcNAQOQBgAwAAAAAQAAAB4AcAABAAAAHwAAAFJFOiBSZTogUHJvYmxl bSBmb3IgcHVibGljIENBcwAAnwoBA5AGAEAAAAABAAAAAgExAAEAAAAtAAAANC4yLjEuMjAw MDAyMTQxNTU2NTguMDNmYWJlYzAoYSltYWlsLmltYy5vcmcAAAAALwwBA5AGAAwAAAABAAAA CwACAAEAAAAPAAEDkAYADAAAAAEAAAADAC4AAAAAADIAAQOQBgAYAAAAAQAAAB4APQABAAAA BQAAAFJFOiAAAAAAUwEBA5AGACwAAAABAAAAHgCZCgggBgAAAAAAwAAAAAAAAEYAAAAAOIUA AAEAAAABAAAAAAAAALUCAQOQBgAsAAAAAQAAAB4AmgoIIAYAAAAAAMAAAAAAAABGAAAAADeF AAABAAAAAQAAAAAAAAC1AgEDkAYALAAAAAEAAAAeAJsKCCAGAAAAAADAAAAAAAAARgAAAAA2 hQAAAQAAAAEAAAAAAAAAtQIBA5AGACQAAAABAAAAAwCcCgggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAB7AgEDkAYAJAAAAAEAAAADAJ0KCCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAA AHUCAQOQBgAkAAAAAQAAAAMAngoIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAdQIBA5AG ACQAAAABAAAACwCfCgggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAB8AgEDkAYAJAAAAAEA AAADAKAKCCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAGgCAQOQBgAwAAAAAQAAAB4AoQoI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAApwMBA5AGACQAAAABAAAA AwCiCgggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPMVAADDAwEDkAYAIAAAAAEAAAACAQswAQAA ABAAAADL4SSqjuPTEbD4AAH61PuWJwoBA5AGAAwAAAABAAAAAwCAEP////+QBAEJAAQAAgAA AAAAAAABA5AGAAwAAAABAAAACwAjAAAAAAAvAAEDkAYADAAAAAEAAAALACkAAAAAADUAAQSQ BgDYAQAAAQAAABIAAAAeAAEwAQAAAA0AAAAnaWV0Zi1zbWltZScAAAAAAgH/DwEAAAA7AAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1zbWltZQBTTVRQAGlldGYtc21pbWVAaW1j Lm9yZwAAAwAVDAEAAAADAAAwAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgAaDAEAAAATAAAA TydNYWxsZXksIEJhcnRsZXkAAAACARkMAQAAAD8AAAAAAAAAjVVM0Ow8Ec6B/wgACbEDegEA AAALAAAAAAAAADEdTydNYWxsZXkeMh1CYXJ0bGV5HjUdNjBFVUxPTgAAHgADMAEAAAATAAAA aWV0Zi1zbWltZUBpbWMub3JnAAADAP9fAAAAAAMA/V8BAAAAHgD2XwEAAAALAAAAaWV0Zi1z bWltZQAAAgH3XwEAAAA7AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1zbWltZQBT TVRQAGlldGYtc21pbWVAaW1jLm9yZwAACwAPDgAABIACAQswAQAAABgAAABTTVRQOklFVEYt U01JTUVASU1DLk9SRwADAP4PBgAAAAMAADkAAAAACwBAOgEAEgADAHE6AAAAAAxc --openmail-part-10d68c22-00000001-- From owner-ietf-smime@imc.org Tue Feb 15 20:37:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00100 for ; Tue, 15 Feb 2000 20:37:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA08720 for ietf-smime-bks; Tue, 15 Feb 2000 16:50:53 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08716 for ; Tue, 15 Feb 2000 16:50:52 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 15 Feb 2000 17:53:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 15 Feb 2000 17:53:27 -0700 From: "Bob Jueneman" To: Subject: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA08717 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Wed Feb 16 06:04:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22063 for ; Wed, 16 Feb 2000 06:04:27 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA27804 for ietf-smime-bks; Wed, 16 Feb 2000 02:23:36 -0800 (PST) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27798 for ; Wed, 16 Feb 2000 02:23:24 -0800 (PST) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 16 Feb 00 10:37:06 -0000 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: from piers2k (host62-172-80-119.host.btclick.com [62.172.80.119]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DW0Z0Y61; Wed, 16 Feb 2000 10:22:41 -0000 Reply-to: piers@bj.co.uk From: "Piers Chivers" To: "'Bob Jueneman'" , ietf-smime@imc.org Subject: RE: E-mail address validation Date: Wed, 16 Feb 2000 10:27:30 -0000 Message-ID: <000301bf7868$6e7ef850$1a01a8c0@piers2k.bj.co.uk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal X-WSS-ID: 14B4A25829729-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bob, I thought this group was concerned about protocol whereas what you are describing is largely human-machine-interface issues. If we are going to get into that arena I could argue that all signed receipts should be displayed as green. I expect that suggestion would be unacceptable to those who like red! Having said that, I think the addressing issues need to be clarified. We have the added complication of combining SMIME and X.400 where there are both P1 and P2 addresses. I mostly agree with your suggestions below but think they need to be worked upon to become definitive. I'm not sure if this WG is the right forum for that discussion? The most difficult approach is to educate users that who routed the message (the envelope addressees) is not necessarily the same as who generated the content. Perhaps our UIs should improve to make this distinction more explicit. Piers -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Bob Jueneman Sent: 16 February 2000 00:53 To: ietf-smime@imc.org Subject: E-mail address validation Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Wed Feb 16 11:31:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05082 for ; Wed, 16 Feb 2000 11:31:52 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA05578 for ietf-smime-bks; Wed, 16 Feb 2000 07:35:57 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05574 for ; Wed, 16 Feb 2000 07:35:56 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08238 for ; Wed, 16 Feb 2000 10:39:56 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA08230 for ; Wed, 16 Feb 2000 10:39:55 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA10253 for ; Wed, 16 Feb 2000 10:39:47 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA15009 for ; Wed, 16 Feb 2000 10:37:01 -0500 (EST) Message-Id: <200002161537.KAA15009@ara.missi.ncsc.mil> Date: Wed, 16 Feb 2000 10:37:01 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: E-mail address validation To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RO+Ll7cTaa/hytNUToLY+w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: "Bob Jueneman" > > [...] > > So let me take a stab at a revised solution that includes both problems, > although this may turn out to be only half-baked. > > 1. The UI for a signed message SHOULD display the originator's "real" common > name, which may be further qualified, if desired. The originator's RFC822 address > from the certificate should also be displayed, and the DN as well, in that order of > preference if those fields are all supplied, but it must be recognized that some > may be missing. Bob, I'm unconvinced that X.509/PKIX/SMIME should define an extension or GeneralName field to contain a "real" common name. That would create more problems than it solves. Yes, there are unusual directory schemas out there, including within the DoD, and they have a substantial amount of inertia. But if there is a corporate policy determination that the "real" common name should be contained in PKI certificates, then it unquestionably would be easier to place it in the CN field of the DN than to procure CAs, directories, and applications with support for an as-yet-undefined field or extension. My stab is that by default the UI should display the Subject CN (always) and the rfc822 address (if present in the cert), with a way for the user to display the full Subject DN or the full cert. If the CN is a bit cryptic, it's up to the organization's CIO to change the schema or leave it as is. Regardless of whether the DN is cryptic or clear, the address book nickname for that cert will always be displayed. > 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from > the certificate to the From address of the message, and SHOULD flag a mismatch, > but MUST NOT require that the RFC822 name be present in the certificate. > > 3. In the event of an encrypted message, including a reply to a From or Reply-to > address, the To, Cc, and Bcc addresses SHOULD all be matched against the > RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE > WAS SELECTED, and SHOULD flag any mismatch with a warning message. > > Does this take care of the problem? Do we need to say something about > checking the outgoing From or Reply-to addresses in the case of a signed message > to make sure they conform to the user's certificate? If so, which certificate -- the > signing certificate, or the encryption certificate? > > Hmm. This gets more and more complicated. > > Bob Don't forget that a single S/MIME message can have multiple nested encryptedData and signedData layers, and that a single signedData can have multiple SignerInfos. Makes the Reply-to, CC, and BCC questions sound simple :-). Paul makes a distinction between the "security standpoint" and the "UI standpoint". I agree with Paul that from the UI standpoint a cert address is not the primary source of return address information. I don't agree that the "security standpoint" is different - if you want a secure Reply-to field, then use signed rfc822 headers, not the contents of the signing cert. My bank will accept a check with my signature without caring whether it entered the postal system from my home address, even though the address is imprinted. The imprinted address serves to identify me, but doesn't limit where I can send or receive snail mail. From owner-ietf-smime@imc.org Wed Feb 16 15:35:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12855 for ; Wed, 16 Feb 2000 15:35:36 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA10831 for ietf-smime-bks; Wed, 16 Feb 2000 11:54:55 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10827 for ; Wed, 16 Feb 2000 11:54:54 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Feb 2000 12:57:52 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 16 Feb 2000 12:55:52 -0700 From: "Bob Jueneman" To: , Subject: Re: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10828 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit David, the syntax for subjectAltName already includes directoryName, so no architectural extension is required. And multiple subjectAltNames are also allowed, explicitly, so no extension is required there either. Now, how many of the existing mail clients support this is a different question, as is the issue of how many CAs support it. Probably none, in fact. But that's to be expected, especially in a standards group. We are trying to decide where we need to go -- if we limit ourselves to existing products and procurement questions, the game is already over. Naturally, I would like to see CIOs change their directory structure to be more accommodating to what certificates need in terms of conveying useful information to relying parties. The problem is, having observed this phenomenon for nearly 10 years now, I haven't seen any movement in that direction at all, and it isn't just intransigence -- there are copious real reasons why directory schemas are what they are, and they aren't terribly likely to change, I'm afraid. So I'm not trying to reinvent the wheel, just trying to take advantage of the wheels that already exist. Your point about message enveloping is quite valid, and tends to make the address comparison issue even more complicated. Bob >>> "David P. Kemp" 02/16/00 08:37AM >>> > From: "Bob Jueneman" > > [...] > > So let me take a stab at a revised solution that includes both problems, > although this may turn out to be only half-baked. > > 1. The UI for a signed message SHOULD display the originator's "real" common > name, which may be further qualified, if desired. The originator's RFC822 address > from the certificate should also be displayed, and the DN as well, in that order of > preference if those fields are all supplied, but it must be recognized that some > may be missing. Bob, I'm unconvinced that X.509/PKIX/SMIME should define an extension or GeneralName field to contain a "real" common name. That would create more problems than it solves. Yes, there are unusual directory schemas out there, including within the DoD, and they have a substantial amount of inertia. But if there is a corporate policy determination that the "real" common name should be contained in PKI certificates, then it unquestionably would be easier to place it in the CN field of the DN than to procure CAs, directories, and applications with support for an as-yet-undefined field or extension. My stab is that by default the UI should display the Subject CN (always) and the rfc822 address (if present in the cert), with a way for the user to display the full Subject DN or the full cert. If the CN is a bit cryptic, it's up to the organization's CIO to change the schema or leave it as is. Regardless of whether the DN is cryptic or clear, the address book nickname for that cert will always be displayed. > 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from > the certificate to the From address of the message, and SHOULD flag a mismatch, > but MUST NOT require that the RFC822 name be present in the certificate. > > 3. In the event of an encrypted message, including a reply to a From or Reply-to > address, the To, Cc, and Bcc addresses SHOULD all be matched against the > RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE > WAS SELECTED, and SHOULD flag any mismatch with a warning message. > > Does this take care of the problem? Do we need to say something about > checking the outgoing From or Reply-to addresses in the case of a signed message > to make sure they conform to the user's certificate? If so, which certificate -- the > signing certificate, or the encryption certificate? > > Hmm. This gets more and more complicated. > > Bob Don't forget that a single S/MIME message can have multiple nested encryptedData and signedData layers, and that a single signedData can have multiple SignerInfos. Makes the Reply-to, CC, and BCC questions sound simple :-). Paul makes a distinction between the "security standpoint" and the "UI standpoint". I agree with Paul that from the UI standpoint a cert address is not the primary source of return address information. I don't agree that the "security standpoint" is different - if you want a secure Reply-to field, then use signed rfc822 headers, not the contents of the signing cert. My bank will accept a check with my signature without caring whether it entered the postal system from my home address, even though the address is imprinted. The imprinted address serves to identify me, but doesn't limit where I can send or receive snail mail. From owner-ietf-smime@imc.org Wed Feb 16 15:49:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13291 for ; Wed, 16 Feb 2000 15:49:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA11071 for ietf-smime-bks; Wed, 16 Feb 2000 12:05:12 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11066 for ; Wed, 16 Feb 2000 12:05:10 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Feb 2000 13:08:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 16 Feb 2000 13:07:59 -0700 From: "Bob Jueneman" To: , Subject: RE: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA11068 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Piers, I certainly agree that the IETF is primarily concerned with protocols, and not APIs and even less issues of look and feel. However, what we are trying to do is to establish an infrastructure for _secure_ communications, and to a very large extent that security is quite literally in the eye of the beholder. To my mind, S/MIME today 'works" but is not "workable", in part because of the difficulty in setting up the infrastructure, but in part because of trying to get these kinds of nuances right. it could be argued that address verification isn't even necessary -- the user could check the certificate whenever it seemed necessary. But what I really don't want to see is a case where a naive user is tricked into accepting a signed message from "President William C. Clinton" .............. just because foo@bar.com had previously been validated in a different context. So, I believe, the human factors issue is important, and at least as relevant to this WG as any other standards issue where the word "SHOULD" is used. Obviously Novell could go off and do its own thing in this space -- the Internet police aren't going to prevent it if we support an additional user name in a subjectAltName in the certificate, and choose to display it in GroupWise. But I'm trying to raise all of the boats, by making sure that the PKI and S/MIME products not only interoperate, but actually do something useful, and don't mislead people. My two cents, anyway. Bob >>> "Piers Chivers" 02/16/00 03:27AM >>> Bob, I thought this group was concerned about protocol whereas what you are describing is largely human-machine-interface issues. If we are going to get into that arena I could argue that all signed receipts should be displayed as green. I expect that suggestion would be unacceptable to those who like red! Having said that, I think the addressing issues need to be clarified. We have the added complication of combining SMIME and X.400 where there are both P1 and P2 addresses. I mostly agree with your suggestions below but think they need to be worked upon to become definitive. I'm not sure if this WG is the right forum for that discussion? The most difficult approach is to educate users that who routed the message (the envelope addressees) is not necessarily the same as who generated the content. Perhaps our UIs should improve to make this distinction more explicit. Piers -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Bob Jueneman Sent: 16 February 2000 00:53 To: ietf-smime@imc.org Subject: E-mail address validation Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Thu Feb 17 03:51:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07908 for ; Thu, 17 Feb 2000 03:51:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA13800 for ietf-smime-bks; Thu, 17 Feb 2000 00:00:46 -0800 (PST) Received: from server1.controlnet.co.in (controlnet.co.in [202.54.116.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13796 for ; Thu, 17 Feb 2000 00:00:41 -0800 (PST) Received: from snprobe1 (snprobe1 [192.168.1.252]) by server1.controlnet.co.in (8.8.7/8.8.7) with SMTP id NAA11548 for ; Thu, 17 Feb 2000 13:20:37 +0530 Message-ID: <012801bf78b9$0d1f9640$fc01a8c0@controlnet.co.in> From: "George Da'Costa" To: Subject: wanted help on fletchers checksum urgently ! Date: Thu, 17 Feb 2000 01:34:37 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01BF78E7.26CB9D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0125_01BF78E7.26CB9D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi !!! well i would be glad if i could get some help on fletchers checksum = algorithm. when checking the checksum for ospf lsa header template which bytes of = the packet need to be considered =20 Any help and references are welcome. Thanx in advance. =20 Regards, George =20 =20 =20 ------=_NextPart_000_0125_01BF78E7.26CB9D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi !!!
well i would be glad if i = could get some=20 help on fletchers checksum algorithm.
when checking the checksum for = ospf lsa=20 header template which bytes of the
packet need to be=20 considered
 
Any help and references are welcome. Thanx in=20 advance.
 
Regards,
George
 
 
 
------=_NextPart_000_0125_01BF78E7.26CB9D40-- From owner-ietf-smime@imc.org Thu Feb 17 09:30:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13954 for ; Thu, 17 Feb 2000 09:30:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22867 for ietf-smime-bks; Thu, 17 Feb 2000 05:51:09 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22863 for ; Thu, 17 Feb 2000 05:51:08 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 0B43D2BA; Thu, 17 Feb 2000 08:53:59 -0500 (EST) Received: from excreo-gh01.reo.dec.com (unknown [16.41.128.40]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id B3FCF3CF for ; Thu, 17 Feb 2000 08:53:58 -0500 (EST) Received: by EXCREO-GH01 with Internet Mail Service (5.5.2650.21) id <10Y4HCDS>; Thu, 17 Feb 2000 13:53:57 -0000 Message-ID: <6B180991CB19D31183E40000F86AF80E2873BE@broexc2.bro.dec.com> From: "De Clercq, Jan" To: "'ietf-smime@imc.org'" Subject: S/MIME and disclaimer Date: Thu, 17 Feb 2000 13:53:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there a way to add a generic disclaimer to S/MIME mail messages after the message has been encrypted / signed? This could happen e.g. on the gateway level... Is there a way to extend multipart MIME messages? Is there a way to add scoping to an S/MIME MIME type? Otherwise text added after the S/MIME operations would invalidate the signature. Would a disclaimer added after signing be readable on the receiver side? Tx, Jan From owner-ietf-smime@imc.org Wed Feb 23 06:56:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18961 for ; Wed, 23 Feb 2000 06:56:07 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA22612 for ietf-smime-bks; Wed, 23 Feb 2000 03:19:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22607 for ; Wed, 23 Feb 2000 03:19:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18210; Wed, 23 Feb 2000 06:23:10 -0500 (EST) Message-Id: <200002231123.GAA18210@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-02.txt Date: Wed, 23 Feb 2000 06:23:10 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Incorporation of IDEA Encryption Algorithm in S/MIME Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-02.txt Pages : 6 Date : 22-Feb-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional algorithm for symmetric encryption. Today, IDEA is widely applied in electronic business applications. But it is not considered in the specification [SMIME3]. Encryption algorithms are part of an organizations' security policy. Typically, organizations like to have their own preferences in this respect. Therefore, it is beneficial to have the choice between different well-known encryption algorithms. Especially for those organization who make already use of IDEA on a wide scale it is of high interest that IDEA is also available in S/MIME. It is the intention of this memo to provide the OIDs and algorithms required to include IDEA in S/MIME for symmetric content and key encryption. The general functional capabilities and preferences of S/MIME are specified by the registered list of S/MIME object identifiers (OIDs). This list of OIDs is maintained by the Internet Mail Consortium at . The set of S/MIME functions provided by a client is expressed by the S/MIME capabilities attribute. This attribute contains a list of OIDs of supported cryptographic functions. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000222092914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000222092914.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Wed Feb 23 13:29:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29323 for ; Wed, 23 Feb 2000 13:29:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28706 for ietf-smime-bks; Wed, 23 Feb 2000 09:54:03 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28702 for ; Wed, 23 Feb 2000 09:54:02 -0800 (PST) Message-Id: <4.2.1.20000223093955.00c4d6e0(null)> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 23 Feb 2000 09:58:46 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: draft-ietf-smime-idea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are a few things in this document that should raise concern. Appendix C states clearly that this is a patented algorithm for which licensing is available. However, it appears that no one has let the IETF Secretariat know that. Nothing about IDEA is listed on . This draft should not be considered until there is a formal statement to the IETF. Parts of the document sounds like a marketing brochure. "Today, IDEA is widely applied in electronic business applications." "Especially for those organization who make already use of IDEA on a wide scale it is of high interest that IDEA is also available in S/MIME." "Experts in cryptography consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. These seem particularly inappropriate for an RFC. To be frank, I've never heard of anyone wanting to use IDEA for anything other than old PGP. The folks who wrote PGP had their reasons for choosing IDEA when they did, but they dropped IDEA as a required algorithm for OpenPGP and that doesn't appear to have negatively affected them. The IETF shouldn't codify this kind of marketing hype, even in an Informational RFC. To move forwards with this, it would be nice if the authors went through the draft and took out the marketing fluff. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Wed Feb 23 14:59:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01586 for ; Wed, 23 Feb 2000 14:59:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00526 for ietf-smime-bks; Wed, 23 Feb 2000 11:19:04 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00521 for ; Wed, 23 Feb 2000 11:19:03 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA19155 for ; Wed, 23 Feb 2000 11:18:27 -0800 (PST) Message-Id: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Feb 2000 14:20:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime@imc.org Wed Feb 23 16:47:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03313 for ; Wed, 23 Feb 2000 16:47:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02003 for ietf-smime-bks; Wed, 23 Feb 2000 13:11:21 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01999 for ; Wed, 23 Feb 2000 13:11:20 -0800 (PST) Message-Id: <4.2.1.20000223125743.00c4c310@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 23 Feb 2000 13:16:05 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> References: <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >3. I would like this document to become a Standards Track document. Not to disagree with the WG chair, but it is unclear why this should be on standards track. It is protocol information for the community about a non-mandatory algorithm that, as far as we can tell, is barely used. Because of that, isn't it much better qualified for Informational RFC? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Thu Feb 24 09:33:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01045 for ; Thu, 24 Feb 2000 09:33:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA08114 for ietf-smime-bks; Thu, 24 Feb 2000 05:52:55 -0800 (PST) Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08110 for ; Thu, 24 Feb 2000 05:52:54 -0800 (PST) Received: by MARS with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 08:56:47 -0500 Message-ID: From: Aram Perez To: ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea Date: Thu, 24 Feb 2000 08:56:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, Paul and others, Is it possible to create a "template" RFC for using algorithms with S/MIME? The CAST-128 document might be a good starting point. Regards, Aram Perez -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Wednesday, February 23, 2000 2:20 PM To: ietf-smime@imc.org Subject: Re: draft-ietf-smime-idea All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime@imc.org Thu Feb 24 16:31:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10940 for ; Thu, 24 Feb 2000 16:31:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16506 for ietf-smime-bks; Thu, 24 Feb 2000 12:53:48 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16501; Thu, 24 Feb 2000 12:53:46 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA02469; Thu, 24 Feb 2000 12:53:12 -0800 (PST) Message-Id: <4.2.0.58.20000224151110.00a4d610@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 15:14:39 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: draft-ietf-smime-idea Cc: ietf-smime@imc.org In-Reply-To: <4.2.1.20000223125743.00c4c310@mail.imc.org> References: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: Take a look at the cipher suite definitions associated with TLS. Only one cipher suite is mandatory to implement, but all of the cipher suite documents are on standards track. The SKIPJACK and KEA document is an exception. The algorithm to wrap one SKIPJACK key with another SKIPJACK key is not specified in a publicly available document. For this reason, it is not appropriate for the document to be on standards track. All of the information to implement is not provided.... Russ At 01:16 PM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >>3. I would like this document to become a Standards Track document. > >Not to disagree with the WG chair, but it is unclear why this should be on >standards track. It is protocol information for the community about a >non-mandatory algorithm that, as far as we can tell, is barely used. >Because of that, isn't it much better qualified for Informational RFC? > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-smime@imc.org Thu Feb 24 17:08:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11665 for ; Thu, 24 Feb 2000 17:08:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17119 for ietf-smime-bks; Thu, 24 Feb 2000 13:40:51 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17115 for ; Thu, 24 Feb 2000 13:40:49 -0800 (PST) Message-Id: <4.2.1.20000224134352.00c4e6f0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 24 Feb 2000 13:45:51 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.0.58.20000224151110.00a4d610@mail.spyrus.com> References: <4.2.1.20000223125743.00c4c310@mail.imc.org> <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:14 PM 2/24/00 -0500, Russ Housley wrote: >Take a look at the cipher suite definitions associated with TLS. Only one >cipher suite is mandatory to implement, but all of the cipher suite >documents are on standards track. If Johnny jumped off a bridge, would you do it? :-) Other WGs are putting things like this on standards track; I don't think that is necessarily a good idea. This can probably be deferred until you talk with the ADs about what they think. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Thu Feb 24 17:24:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11886 for ; Thu, 24 Feb 2000 17:24:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17277 for ietf-smime-bks; Thu, 24 Feb 2000 13:48:46 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17273 for ; Thu, 24 Feb 2000 13:48:45 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA03153; Thu, 24 Feb 2000 13:48:11 -0800 (PST) Message-Id: <4.2.0.58.20000224162733.00942b60@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 16:29:08 -0500 To: Aram Perez From: Russ Housley Subject: RE: draft-ietf-smime-idea Cc: ietf-smime@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Aram: The subsection within section 6 of RFC 2630 are a good start. It really depends what kind of algorithm is being specified: encryption, hash, key management, signature, or key wrap. Russ At 08:56 AM 02/24/2000 -0500, Aram Perez wrote: >Hi Russ, Paul and others, > >Is it possible to create a "template" RFC for using algorithms with S/MIME? >The CAST-128 document might be a good starting point. > >Regards, >Aram Perez > > >-----Original Message----- >From: Russ Housley [mailto:housley@spyrus.com] >Sent: Wednesday, February 23, 2000 2:20 PM >To: ietf-smime@imc.org >Subject: Re: draft-ietf-smime-idea > > >All: > >Paul raises some very important points. Let me share my view as the S/MIME >Working Group Chair. > >1. We must have an IPR statement for this document to progress to an RFC. > >2. I do not mind some justification text. Something like: "Organization >who make already use of IDEA for other applications also want to use IDEA >in S/MIME." But, in my opinion, the marketing hype needs to be >significantly reduced. The CAST-128 document does not try to convince >anyone that CAST-128 is appropriate or inappropriate for any particular >group of users. The IDEA document should have a similar tone. > >3. I would like this document to become a Standards Track document. The >document should state the one and only way that IDEA is used with >CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is >implemented, then it MUST be done in the manner specified in this >document. I cannot recommend that this document become a Standards Track >RFC until items 1 and 2 are repaired. > >Russ > > >At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: > >There are a few things in this document that should raise concern. > > > >Appendix C states clearly that this is a patented algorithm for which > >licensing is available. However, it appears that no one has let the IETF > >Secretariat know that. Nothing about IDEA is listed on > >. This draft should not be considered until > >there is a formal statement to the IETF. > > > >Parts of the document sounds like a marketing brochure. "Today, IDEA is > >widely applied in electronic business applications." "Especially for those > >organization who make already use of IDEA on a wide scale it is of high > >interest that IDEA is also available in S/MIME." "Experts in cryptography > >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > > > >These seem particularly inappropriate for an RFC. To be frank, I've never > >heard of anyone wanting to use IDEA for anything other than old PGP. The > >folks who wrote PGP had their reasons for choosing IDEA when they did, but > >they dropped IDEA as a required algorithm for OpenPGP and that doesn't > >appear to have negatively affected them. The IETF shouldn't codify this > >kind of marketing hype, even in an Informational RFC. To move forwards > >with this, it would be nice if the authors went through the draft and took > >out the marketing fluff. > > > >--Paul Hoffman, Director > >--Internet Mail Consortium From owner-ietf-smime@imc.org Fri Feb 25 01:52:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23842 for ; Fri, 25 Feb 2000 01:52:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA07411 for ietf-smime-bks; Thu, 24 Feb 2000 22:17:57 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA07407 for ; Thu, 24 Feb 2000 22:17:56 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2000 23:21:29 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 24 Feb 2000 23:21:13 -0700 From: "Bob Jueneman" To: , Subject: Re: draft-ietf-smime-idea Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA07408 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit "The wonderful thing about standards is that there are so many to choose from." I strongly agree with Paul. I am not aware of ANY kind of a significant ground swell for IDEA, especially with the relaxation of the US export regulations and the wider availability of triple-DES and the forthcoming AES algorithm(s). In fact, I think there are already FAR too many algorithms, variations, etc., in the S/MIME standard as it is, and to virtually no good purpose that I can see. Unless a particular algorithm is obviously off the wall, the tendency is for every implementation to include every algorithm, regardless of the actual number of users. Some Program Manager somewhere will say, "But what if customer B want to use algorithm X, and we don't support it. Then customer A would not be able to communicate with him, and we might lose sales." And pretty soon, the product is up to 60 megabytes in size, chock full of unused options, and everyone wonders why the product is so bloated and hard to use, not to mention all of the interoperability problems caused for the customers. It's high time to say ENOUGH, and to kill off this sort of useless nonsense while it is still budding, without consuming useless cycles debating the format of the document, the IPR issues, etc., etc. Bob >>> Paul Hoffman / IMC 02/23/00 10:58AM >>> [snip] To be frank, I've never heard of anyone wanting to use IDEA for anything other than old PGP. The folks who wrote PGP had their reasons for choosing IDEA when they did, but they dropped IDEA as a required algorithm for OpenPGP and that doesn't appear to have negatively affected them. The IETF shouldn't codify this kind of marketing hype, even in an Informational RFC. [snip] --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id WAA07411 for ietf-smime-bks; Thu, 24 Feb 2000 22:17:57 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA07407 for ; Thu, 24 Feb 2000 22:17:56 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2000 23:21:29 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 24 Feb 2000 23:21:13 -0700 From: "Bob Jueneman" To: , Subject: Re: draft-ietf-smime-idea Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA07408 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "The wonderful thing about standards is that there are so many to choose from." I strongly agree with Paul. I am not aware of ANY kind of a significant ground swell for IDEA, especially with the relaxation of the US export regulations and the wider availability of triple-DES and the forthcoming AES algorithm(s). In fact, I think there are already FAR too many algorithms, variations, etc., in the S/MIME standard as it is, and to virtually no good purpose that I can see. Unless a particular algorithm is obviously off the wall, the tendency is for every implementation to include every algorithm, regardless of the actual number of users. Some Program Manager somewhere will say, "But what if customer B want to use algorithm X, and we don't support it. Then customer A would not be able to communicate with him, and we might lose sales." And pretty soon, the product is up to 60 megabytes in size, chock full of unused options, and everyone wonders why the product is so bloated and hard to use, not to mention all of the interoperability problems caused for the customers. It's high time to say ENOUGH, and to kill off this sort of useless nonsense while it is still budding, without consuming useless cycles debating the format of the document, the IPR issues, etc., etc. Bob >>> Paul Hoffman / IMC 02/23/00 10:58AM >>> [snip] To be frank, I've never heard of anyone wanting to use IDEA for anything other than old PGP. The folks who wrote PGP had their reasons for choosing IDEA when they did, but they dropped IDEA as a required algorithm for OpenPGP and that doesn't appear to have negatively affected them. The IETF shouldn't codify this kind of marketing hype, even in an Informational RFC. [snip] --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17277 for ietf-smime-bks; Thu, 24 Feb 2000 13:48:46 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17273 for ; Thu, 24 Feb 2000 13:48:45 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA03153; Thu, 24 Feb 2000 13:48:11 -0800 (PST) Message-Id: <4.2.0.58.20000224162733.00942b60@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 16:29:08 -0500 To: Aram Perez From: Russ Housley Subject: RE: draft-ietf-smime-idea Cc: ietf-smime@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Aram: The subsection within section 6 of RFC 2630 are a good start. It really depends what kind of algorithm is being specified: encryption, hash, key management, signature, or key wrap. Russ At 08:56 AM 02/24/2000 -0500, Aram Perez wrote: >Hi Russ, Paul and others, > >Is it possible to create a "template" RFC for using algorithms with S/MIME? >The CAST-128 document might be a good starting point. > >Regards, >Aram Perez > > >-----Original Message----- >From: Russ Housley [mailto:housley@spyrus.com] >Sent: Wednesday, February 23, 2000 2:20 PM >To: ietf-smime@imc.org >Subject: Re: draft-ietf-smime-idea > > >All: > >Paul raises some very important points. Let me share my view as the S/MIME >Working Group Chair. > >1. We must have an IPR statement for this document to progress to an RFC. > >2. I do not mind some justification text. Something like: "Organization >who make already use of IDEA for other applications also want to use IDEA >in S/MIME." But, in my opinion, the marketing hype needs to be >significantly reduced. The CAST-128 document does not try to convince >anyone that CAST-128 is appropriate or inappropriate for any particular >group of users. The IDEA document should have a similar tone. > >3. I would like this document to become a Standards Track document. The >document should state the one and only way that IDEA is used with >CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is >implemented, then it MUST be done in the manner specified in this >document. I cannot recommend that this document become a Standards Track >RFC until items 1 and 2 are repaired. > >Russ > > >At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: > >There are a few things in this document that should raise concern. > > > >Appendix C states clearly that this is a patented algorithm for which > >licensing is available. However, it appears that no one has let the IETF > >Secretariat know that. Nothing about IDEA is listed on > >. This draft should not be considered until > >there is a formal statement to the IETF. > > > >Parts of the document sounds like a marketing brochure. "Today, IDEA is > >widely applied in electronic business applications." "Especially for those > >organization who make already use of IDEA on a wide scale it is of high > >interest that IDEA is also available in S/MIME." "Experts in cryptography > >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > > > >These seem particularly inappropriate for an RFC. To be frank, I've never > >heard of anyone wanting to use IDEA for anything other than old PGP. The > >folks who wrote PGP had their reasons for choosing IDEA when they did, but > >they dropped IDEA as a required algorithm for OpenPGP and that doesn't > >appear to have negatively affected them. The IETF shouldn't codify this > >kind of marketing hype, even in an Informational RFC. To move forwards > >with this, it would be nice if the authors went through the draft and took > >out the marketing fluff. > > > >--Paul Hoffman, Director > >--Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17119 for ietf-smime-bks; Thu, 24 Feb 2000 13:40:51 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17115 for ; Thu, 24 Feb 2000 13:40:49 -0800 (PST) Message-Id: <4.2.1.20000224134352.00c4e6f0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 24 Feb 2000 13:45:51 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.0.58.20000224151110.00a4d610@mail.spyrus.com> References: <4.2.1.20000223125743.00c4c310@mail.imc.org> <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:14 PM 2/24/00 -0500, Russ Housley wrote: >Take a look at the cipher suite definitions associated with TLS. Only one >cipher suite is mandatory to implement, but all of the cipher suite >documents are on standards track. If Johnny jumped off a bridge, would you do it? :-) Other WGs are putting things like this on standards track; I don't think that is necessarily a good idea. This can probably be deferred until you talk with the ADs about what they think. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16506 for ietf-smime-bks; Thu, 24 Feb 2000 12:53:48 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16501; Thu, 24 Feb 2000 12:53:46 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA02469; Thu, 24 Feb 2000 12:53:12 -0800 (PST) Message-Id: <4.2.0.58.20000224151110.00a4d610@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 15:14:39 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: draft-ietf-smime-idea Cc: ietf-smime@imc.org In-Reply-To: <4.2.1.20000223125743.00c4c310@mail.imc.org> References: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: Take a look at the cipher suite definitions associated with TLS. Only one cipher suite is mandatory to implement, but all of the cipher suite documents are on standards track. The SKIPJACK and KEA document is an exception. The algorithm to wrap one SKIPJACK key with another SKIPJACK key is not specified in a publicly available document. For this reason, it is not appropriate for the document to be on standards track. All of the information to implement is not provided.... Russ At 01:16 PM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >>3. I would like this document to become a Standards Track document. > >Not to disagree with the WG chair, but it is unclear why this should be on >standards track. It is protocol information for the community about a >non-mandatory algorithm that, as far as we can tell, is barely used. >Because of that, isn't it much better qualified for Informational RFC? > >--Paul Hoffman, Director >--Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id FAA08114 for ietf-smime-bks; Thu, 24 Feb 2000 05:52:55 -0800 (PST) Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08110 for ; Thu, 24 Feb 2000 05:52:54 -0800 (PST) Received: by MARS with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 08:56:47 -0500 Message-ID: From: Aram Perez To: ietf-smime@imc.org Subject: RE: draft-ietf-smime-idea Date: Thu, 24 Feb 2000 08:56:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Russ, Paul and others, Is it possible to create a "template" RFC for using algorithms with S/MIME? The CAST-128 document might be a good starting point. Regards, Aram Perez -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Wednesday, February 23, 2000 2:20 PM To: ietf-smime@imc.org Subject: Re: draft-ietf-smime-idea All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02003 for ietf-smime-bks; Wed, 23 Feb 2000 13:11:21 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01999 for ; Wed, 23 Feb 2000 13:11:20 -0800 (PST) Message-Id: <4.2.1.20000223125743.00c4c310@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 23 Feb 2000 13:16:05 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> References: <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >3. I would like this document to become a Standards Track document. Not to disagree with the WG chair, but it is unclear why this should be on standards track. It is protocol information for the community about a non-mandatory algorithm that, as far as we can tell, is barely used. Because of that, isn't it much better qualified for Informational RFC? --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00526 for ietf-smime-bks; Wed, 23 Feb 2000 11:19:04 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00521 for ; Wed, 23 Feb 2000 11:19:03 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA19155 for ; Wed, 23 Feb 2000 11:18:27 -0800 (PST) Message-Id: <4.2.0.58.20000223140700.00a473e0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Feb 2000 14:20:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: draft-ietf-smime-idea In-Reply-To: <4.2.1.20000223093955.00c4d6e0(null)> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: Paul raises some very important points. Let me share my view as the S/MIME Working Group Chair. 1. We must have an IPR statement for this document to progress to an RFC. 2. I do not mind some justification text. Something like: "Organization who make already use of IDEA for other applications also want to use IDEA in S/MIME." But, in my opinion, the marketing hype needs to be significantly reduced. The CAST-128 document does not try to convince anyone that CAST-128 is appropriate or inappropriate for any particular group of users. The IDEA document should have a similar tone. 3. I would like this document to become a Standards Track document. The document should state the one and only way that IDEA is used with CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is implemented, then it MUST be done in the manner specified in this document. I cannot recommend that this document become a Standards Track RFC until items 1 and 2 are repaired. Russ At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote: >There are a few things in this document that should raise concern. > >Appendix C states clearly that this is a patented algorithm for which >licensing is available. However, it appears that no one has let the IETF >Secretariat know that. Nothing about IDEA is listed on >. This draft should not be considered until >there is a formal statement to the IETF. > >Parts of the document sounds like a marketing brochure. "Today, IDEA is >widely applied in electronic business applications." "Especially for those >organization who make already use of IDEA on a wide scale it is of high >interest that IDEA is also available in S/MIME." "Experts in cryptography >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. > >These seem particularly inappropriate for an RFC. To be frank, I've never >heard of anyone wanting to use IDEA for anything other than old PGP. The >folks who wrote PGP had their reasons for choosing IDEA when they did, but >they dropped IDEA as a required algorithm for OpenPGP and that doesn't >appear to have negatively affected them. The IETF shouldn't codify this >kind of marketing hype, even in an Informational RFC. To move forwards >with this, it would be nice if the authors went through the draft and took >out the marketing fluff. > >--Paul Hoffman, Director >--Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28706 for ietf-smime-bks; Wed, 23 Feb 2000 09:54:03 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28702 for ; Wed, 23 Feb 2000 09:54:02 -0800 (PST) Message-Id: <4.2.1.20000223093955.00c4d6e0(null)> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 23 Feb 2000 09:58:46 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: draft-ietf-smime-idea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are a few things in this document that should raise concern. Appendix C states clearly that this is a patented algorithm for which licensing is available. However, it appears that no one has let the IETF Secretariat know that. Nothing about IDEA is listed on . This draft should not be considered until there is a formal statement to the IETF. Parts of the document sounds like a marketing brochure. "Today, IDEA is widely applied in electronic business applications." "Especially for those organization who make already use of IDEA on a wide scale it is of high interest that IDEA is also available in S/MIME." "Experts in cryptography consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on. These seem particularly inappropriate for an RFC. To be frank, I've never heard of anyone wanting to use IDEA for anything other than old PGP. The folks who wrote PGP had their reasons for choosing IDEA when they did, but they dropped IDEA as a required algorithm for OpenPGP and that doesn't appear to have negatively affected them. The IETF shouldn't codify this kind of marketing hype, even in an Informational RFC. To move forwards with this, it would be nice if the authors went through the draft and took out the marketing fluff. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA22612 for ietf-smime-bks; Wed, 23 Feb 2000 03:19:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22607 for ; Wed, 23 Feb 2000 03:19:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18210; Wed, 23 Feb 2000 06:23:10 -0500 (EST) Message-Id: <200002231123.GAA18210@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-idea-02.txt Date: Wed, 23 Feb 2000 06:23:10 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Incorporation of IDEA Encryption Algorithm in S/MIME Author(s) : S. Teiwes, P. Hartmann, D. Kuenzi Filename : draft-ietf-smime-idea-02.txt Pages : 6 Date : 22-Feb-00 This memo specifies how to incorporate IDEA (International Data Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an additional algorithm for symmetric encryption. Today, IDEA is widely applied in electronic business applications. But it is not considered in the specification [SMIME3]. Encryption algorithms are part of an organizations' security policy. Typically, organizations like to have their own preferences in this respect. Therefore, it is beneficial to have the choice between different well-known encryption algorithms. Especially for those organization who make already use of IDEA on a wide scale it is of high interest that IDEA is also available in S/MIME. It is the intention of this memo to provide the OIDs and algorithms required to include IDEA in S/MIME for symmetric content and key encryption. The general functional capabilities and preferences of S/MIME are specified by the registered list of S/MIME object identifiers (OIDs). This list of OIDs is maintained by the Internet Mail Consortium at . The set of S/MIME functions provided by a client is expressed by the S/MIME capabilities attribute. This attribute contains a list of OIDs of supported cryptographic functions. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-idea-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-idea-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000222092914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-idea-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-idea-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000222092914.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22867 for ietf-smime-bks; Thu, 17 Feb 2000 05:51:09 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22863 for ; Thu, 17 Feb 2000 05:51:08 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 0B43D2BA; Thu, 17 Feb 2000 08:53:59 -0500 (EST) Received: from excreo-gh01.reo.dec.com (unknown [16.41.128.40]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id B3FCF3CF for ; Thu, 17 Feb 2000 08:53:58 -0500 (EST) Received: by EXCREO-GH01 with Internet Mail Service (5.5.2650.21) id <10Y4HCDS>; Thu, 17 Feb 2000 13:53:57 -0000 Message-ID: <6B180991CB19D31183E40000F86AF80E2873BE@broexc2.bro.dec.com> From: "De Clercq, Jan" To: "'ietf-smime@imc.org'" Subject: S/MIME and disclaimer Date: Thu, 17 Feb 2000 13:53:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there a way to add a generic disclaimer to S/MIME mail messages after the message has been encrypted / signed? This could happen e.g. on the gateway level... Is there a way to extend multipart MIME messages? Is there a way to add scoping to an S/MIME MIME type? Otherwise text added after the S/MIME operations would invalidate the signature. Would a disclaimer added after signing be readable on the receiver side? Tx, Jan Received: by ns.secondary.com (8.9.3/8.9.3) id AAA13800 for ietf-smime-bks; Thu, 17 Feb 2000 00:00:46 -0800 (PST) Received: from server1.controlnet.co.in (controlnet.co.in [202.54.116.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13796 for ; Thu, 17 Feb 2000 00:00:41 -0800 (PST) Received: from snprobe1 (snprobe1 [192.168.1.252]) by server1.controlnet.co.in (8.8.7/8.8.7) with SMTP id NAA11548 for ; Thu, 17 Feb 2000 13:20:37 +0530 Message-ID: <012801bf78b9$0d1f9640$fc01a8c0@controlnet.co.in> From: "George Da'Costa" To: Subject: wanted help on fletchers checksum urgently ! Date: Thu, 17 Feb 2000 01:34:37 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01BF78E7.26CB9D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0125_01BF78E7.26CB9D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi !!! well i would be glad if i could get some help on fletchers checksum = algorithm. when checking the checksum for ospf lsa header template which bytes of = the packet need to be considered =20 Any help and references are welcome. Thanx in advance. =20 Regards, George =20 =20 =20 ------=_NextPart_000_0125_01BF78E7.26CB9D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi !!!
well i would be glad if i = could get some=20 help on fletchers checksum algorithm.
when checking the checksum for = ospf lsa=20 header template which bytes of the
packet need to be=20 considered
 
Any help and references are welcome. Thanx in=20 advance.
 
Regards,
George
 
 
 
------=_NextPart_000_0125_01BF78E7.26CB9D40-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA11071 for ietf-smime-bks; Wed, 16 Feb 2000 12:05:12 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11066 for ; Wed, 16 Feb 2000 12:05:10 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Feb 2000 13:08:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 16 Feb 2000 13:07:59 -0700 From: "Bob Jueneman" To: , Subject: RE: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA11068 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Piers, I certainly agree that the IETF is primarily concerned with protocols, and not APIs and even less issues of look and feel. However, what we are trying to do is to establish an infrastructure for _secure_ communications, and to a very large extent that security is quite literally in the eye of the beholder. To my mind, S/MIME today 'works" but is not "workable", in part because of the difficulty in setting up the infrastructure, but in part because of trying to get these kinds of nuances right. it could be argued that address verification isn't even necessary -- the user could check the certificate whenever it seemed necessary. But what I really don't want to see is a case where a naive user is tricked into accepting a signed message from "President William C. Clinton" .............. just because foo@bar.com had previously been validated in a different context. So, I believe, the human factors issue is important, and at least as relevant to this WG as any other standards issue where the word "SHOULD" is used. Obviously Novell could go off and do its own thing in this space -- the Internet police aren't going to prevent it if we support an additional user name in a subjectAltName in the certificate, and choose to display it in GroupWise. But I'm trying to raise all of the boats, by making sure that the PKI and S/MIME products not only interoperate, but actually do something useful, and don't mislead people. My two cents, anyway. Bob >>> "Piers Chivers" 02/16/00 03:27AM >>> Bob, I thought this group was concerned about protocol whereas what you are describing is largely human-machine-interface issues. If we are going to get into that arena I could argue that all signed receipts should be displayed as green. I expect that suggestion would be unacceptable to those who like red! Having said that, I think the addressing issues need to be clarified. We have the added complication of combining SMIME and X.400 where there are both P1 and P2 addresses. I mostly agree with your suggestions below but think they need to be worked upon to become definitive. I'm not sure if this WG is the right forum for that discussion? The most difficult approach is to educate users that who routed the message (the envelope addressees) is not necessarily the same as who generated the content. Perhaps our UIs should improve to make this distinction more explicit. Piers -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Bob Jueneman Sent: 16 February 2000 00:53 To: ietf-smime@imc.org Subject: E-mail address validation Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA10831 for ietf-smime-bks; Wed, 16 Feb 2000 11:54:55 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10827 for ; Wed, 16 Feb 2000 11:54:54 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Feb 2000 12:57:52 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 16 Feb 2000 12:55:52 -0700 From: "Bob Jueneman" To: , Subject: Re: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10828 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, the syntax for subjectAltName already includes directoryName, so no architectural extension is required. And multiple subjectAltNames are also allowed, explicitly, so no extension is required there either. Now, how many of the existing mail clients support this is a different question, as is the issue of how many CAs support it. Probably none, in fact. But that's to be expected, especially in a standards group. We are trying to decide where we need to go -- if we limit ourselves to existing products and procurement questions, the game is already over. Naturally, I would like to see CIOs change their directory structure to be more accommodating to what certificates need in terms of conveying useful information to relying parties. The problem is, having observed this phenomenon for nearly 10 years now, I haven't seen any movement in that direction at all, and it isn't just intransigence -- there are copious real reasons why directory schemas are what they are, and they aren't terribly likely to change, I'm afraid. So I'm not trying to reinvent the wheel, just trying to take advantage of the wheels that already exist. Your point about message enveloping is quite valid, and tends to make the address comparison issue even more complicated. Bob >>> "David P. Kemp" 02/16/00 08:37AM >>> > From: "Bob Jueneman" > > [...] > > So let me take a stab at a revised solution that includes both problems, > although this may turn out to be only half-baked. > > 1. The UI for a signed message SHOULD display the originator's "real" common > name, which may be further qualified, if desired. The originator's RFC822 address > from the certificate should also be displayed, and the DN as well, in that order of > preference if those fields are all supplied, but it must be recognized that some > may be missing. Bob, I'm unconvinced that X.509/PKIX/SMIME should define an extension or GeneralName field to contain a "real" common name. That would create more problems than it solves. Yes, there are unusual directory schemas out there, including within the DoD, and they have a substantial amount of inertia. But if there is a corporate policy determination that the "real" common name should be contained in PKI certificates, then it unquestionably would be easier to place it in the CN field of the DN than to procure CAs, directories, and applications with support for an as-yet-undefined field or extension. My stab is that by default the UI should display the Subject CN (always) and the rfc822 address (if present in the cert), with a way for the user to display the full Subject DN or the full cert. If the CN is a bit cryptic, it's up to the organization's CIO to change the schema or leave it as is. Regardless of whether the DN is cryptic or clear, the address book nickname for that cert will always be displayed. > 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from > the certificate to the From address of the message, and SHOULD flag a mismatch, > but MUST NOT require that the RFC822 name be present in the certificate. > > 3. In the event of an encrypted message, including a reply to a From or Reply-to > address, the To, Cc, and Bcc addresses SHOULD all be matched against the > RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE > WAS SELECTED, and SHOULD flag any mismatch with a warning message. > > Does this take care of the problem? Do we need to say something about > checking the outgoing From or Reply-to addresses in the case of a signed message > to make sure they conform to the user's certificate? If so, which certificate -- the > signing certificate, or the encryption certificate? > > Hmm. This gets more and more complicated. > > Bob Don't forget that a single S/MIME message can have multiple nested encryptedData and signedData layers, and that a single signedData can have multiple SignerInfos. Makes the Reply-to, CC, and BCC questions sound simple :-). Paul makes a distinction between the "security standpoint" and the "UI standpoint". I agree with Paul that from the UI standpoint a cert address is not the primary source of return address information. I don't agree that the "security standpoint" is different - if you want a secure Reply-to field, then use signed rfc822 headers, not the contents of the signing cert. My bank will accept a check with my signature without caring whether it entered the postal system from my home address, even though the address is imprinted. The imprinted address serves to identify me, but doesn't limit where I can send or receive snail mail. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA05578 for ietf-smime-bks; Wed, 16 Feb 2000 07:35:57 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05574 for ; Wed, 16 Feb 2000 07:35:56 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08238 for ; Wed, 16 Feb 2000 10:39:56 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA08230 for ; Wed, 16 Feb 2000 10:39:55 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA10253 for ; Wed, 16 Feb 2000 10:39:47 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA15009 for ; Wed, 16 Feb 2000 10:37:01 -0500 (EST) Message-Id: <200002161537.KAA15009@ara.missi.ncsc.mil> Date: Wed, 16 Feb 2000 10:37:01 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: E-mail address validation To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RO+Ll7cTaa/hytNUToLY+w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: "Bob Jueneman" > > [...] > > So let me take a stab at a revised solution that includes both problems, > although this may turn out to be only half-baked. > > 1. The UI for a signed message SHOULD display the originator's "real" common > name, which may be further qualified, if desired. The originator's RFC822 address > from the certificate should also be displayed, and the DN as well, in that order of > preference if those fields are all supplied, but it must be recognized that some > may be missing. Bob, I'm unconvinced that X.509/PKIX/SMIME should define an extension or GeneralName field to contain a "real" common name. That would create more problems than it solves. Yes, there are unusual directory schemas out there, including within the DoD, and they have a substantial amount of inertia. But if there is a corporate policy determination that the "real" common name should be contained in PKI certificates, then it unquestionably would be easier to place it in the CN field of the DN than to procure CAs, directories, and applications with support for an as-yet-undefined field or extension. My stab is that by default the UI should display the Subject CN (always) and the rfc822 address (if present in the cert), with a way for the user to display the full Subject DN or the full cert. If the CN is a bit cryptic, it's up to the organization's CIO to change the schema or leave it as is. Regardless of whether the DN is cryptic or clear, the address book nickname for that cert will always be displayed. > 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from > the certificate to the From address of the message, and SHOULD flag a mismatch, > but MUST NOT require that the RFC822 name be present in the certificate. > > 3. In the event of an encrypted message, including a reply to a From or Reply-to > address, the To, Cc, and Bcc addresses SHOULD all be matched against the > RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE > WAS SELECTED, and SHOULD flag any mismatch with a warning message. > > Does this take care of the problem? Do we need to say something about > checking the outgoing From or Reply-to addresses in the case of a signed message > to make sure they conform to the user's certificate? If so, which certificate -- the > signing certificate, or the encryption certificate? > > Hmm. This gets more and more complicated. > > Bob Don't forget that a single S/MIME message can have multiple nested encryptedData and signedData layers, and that a single signedData can have multiple SignerInfos. Makes the Reply-to, CC, and BCC questions sound simple :-). Paul makes a distinction between the "security standpoint" and the "UI standpoint". I agree with Paul that from the UI standpoint a cert address is not the primary source of return address information. I don't agree that the "security standpoint" is different - if you want a secure Reply-to field, then use signed rfc822 headers, not the contents of the signing cert. My bank will accept a check with my signature without caring whether it entered the postal system from my home address, even though the address is imprinted. The imprinted address serves to identify me, but doesn't limit where I can send or receive snail mail. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA27804 for ietf-smime-bks; Wed, 16 Feb 2000 02:23:36 -0800 (PST) Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27798 for ; Wed, 16 Feb 2000 02:23:24 -0800 (PST) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 16 Feb 00 10:37:06 -0000 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: from piers2k (host62-172-80-119.host.btclick.com [62.172.80.119]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DW0Z0Y61; Wed, 16 Feb 2000 10:22:41 -0000 Reply-to: piers@bj.co.uk From: "Piers Chivers" To: "'Bob Jueneman'" , ietf-smime@imc.org Subject: RE: E-mail address validation Date: Wed, 16 Feb 2000 10:27:30 -0000 Message-ID: <000301bf7868$6e7ef850$1a01a8c0@piers2k.bj.co.uk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal X-WSS-ID: 14B4A25829729-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, I thought this group was concerned about protocol whereas what you are describing is largely human-machine-interface issues. If we are going to get into that arena I could argue that all signed receipts should be displayed as green. I expect that suggestion would be unacceptable to those who like red! Having said that, I think the addressing issues need to be clarified. We have the added complication of combining SMIME and X.400 where there are both P1 and P2 addresses. I mostly agree with your suggestions below but think they need to be worked upon to become definitive. I'm not sure if this WG is the right forum for that discussion? The most difficult approach is to educate users that who routed the message (the envelope addressees) is not necessarily the same as who generated the content. Perhaps our UIs should improve to make this distinction more explicit. Piers -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Bob Jueneman Sent: 16 February 2000 00:53 To: ietf-smime@imc.org Subject: E-mail address validation Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA08720 for ietf-smime-bks; Tue, 15 Feb 2000 16:50:53 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08716 for ; Tue, 15 Feb 2000 16:50:52 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 15 Feb 2000 17:53:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 15 Feb 2000 17:53:27 -0700 From: "Bob Jueneman" To: Subject: E-mail address validation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA08717 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul and Bartley make a good point regarding who the reply should be sent to. Although this a second order problem, it still appears to be a problem. The first issue is what should be displayed as the confirmed originator/signer of the message. and I think we are beginning to get a handle on that problem. The second issue is one of routing the reply, and here there are so many differences in the way replies are handled that I'm not even sure I understand all of the problems, much less the solutions. I do know that mail lists frequently mangle the From address, putting the address of the mail list in the cc list, etc., etc. Likewise, people that have multiple accounts for a number of different reasons often use a single Reply-To address to consolidate responses. And if the reply is encrypted, it seems a bit much to ask the sender to somehow read my mind as to which processor containing which certificate/key I am going to use to decrypt the response. And finally, if this is a really serious security issue, which I'm not quite convinced that it is, what should be done about all of the other To, Cc, and Bcc addressees? So let me take a stab at a revised solution that includes both problems, although this may turn out to be only half-baked. 1. The UI for a signed message SHOULD display the originator's "real" common name, which may be further qualified, if desired. The originator's RFC822 address from the certificate should also be displayed, and the DN as well, in that order of preference if those fields are all supplied, but it must be recognized that some may be missing. 2. The UI SHOULD attempt to match the originator's RFC822 addr-spec address from the certificate to the From address of the message, and SHOULD flag a mismatch, but MUST NOT require that the RFC822 name be present in the certificate. 3. In the event of an encrypted message, including a reply to a From or Reply-to address, the To, Cc, and Bcc addresses SHOULD all be matched against the RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE WAS SELECTED, and SHOULD flag any mismatch with a warning message. Does this take care of the problem? Do we need to say something about checking the outgoing From or Reply-to addresses in the case of a signed message to make sure they conform to the user's certificate? If so, which certificate -- the signing certificate, or the encryption certificate? Hmm. This gets more and more complicated. Bob >>> 02/15/00 03:29AM >>> Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA16729 for ietf-smime-bks; Tue, 15 Feb 2000 02:25:31 -0800 (PST) Received: from citicorp.com (mango2-a.citicorp.com [192.193.196.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16725 for ; Tue, 15 Feb 2000 02:25:29 -0800 (PST) From: bartley.o'malley@citicorp.com Received: from myrtle2.citicorp.com (imta.citicorp.com [192.193.195.189]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12103 for ; Tue, 15 Feb 2000 05:26:17 -0500 (EST) Received: from x400prod2.cgin.us-md.citicorp.com (root@wtprod2.cgin.us-md.citicorp.com [163.39.141.206]) by myrtle2.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA12025 for ; Tue, 15 Feb 2000 05:29:21 -0500 (EST) Received: from mercury.lew.gb.citicorp.com (root@mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA03863 Tue, 15 Feb 2000 05:29:20 -0500 (EST) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02037 for ietf-smime@imc.org; Tue, 15 Feb 2000 10:29:17 GMT X-OpenMail-Hops: 1 Date: Tue, 15 Feb 2000 10:29:11 +0000 Message-Id: Subject: RE: Re: Problem for public CAs MIME-Version: 1.0 TO: ietf-smime@imc.org Content-Type: multipart/mixed; boundary="openmail-part-10d68c22-00000001" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --openmail-part-10d68c22-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit Just to play Devils advocate... There is a third address to be considered, the Reply-to. This is a specific request from the originator of the message to reply to another address. If it is present we ought not reply to either of the other 2 addresses. Regards, Bartley O'Malley Citibank NA Lewisham House 25 Molesworth Street London SE13 7EX England Tel +44-020-7500-6473 Fax +44-020-7500-8880 -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Tuesday, February 15, 2000 12:01 AM To: ietf-smime Cc: phoffman Subject: Re: Problem for public CAs At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium --openmail-part-10d68c22-00000001 Content-Type: application/ms-tnef; name="WINMAIL.DAT" Content-Disposition: attachment; filename="WINMAIL.DAT" Content-Transfer-Encoding: base64 eJ8+IqQ+AQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABAB8AAABSRTogUmU6IFByb2JsZW0gZm9y IHB1YmxpYyBDQXMA8AkBA5AGABAAAAABAAAAQAA5ADBk+lKfd78BMAQBA5AGABQAAAABAAAA HgBCEAEAAAABAAAAAAAAAHMAAQOQBgAoAAAAAQAAAAIBcQABAAAAFgAAAAG/d59S2Kok4d/j jhHTsPgAAfrU+5YAAHcNAQOQBgAwAAAAAQAAAB4AcAABAAAAHwAAAFJFOiBSZTogUHJvYmxl bSBmb3IgcHVibGljIENBcwAAnwoBA5AGAEAAAAABAAAAAgExAAEAAAAtAAAANC4yLjEuMjAw MDAyMTQxNTU2NTguMDNmYWJlYzAoYSltYWlsLmltYy5vcmcAAAAALwwBA5AGAAwAAAABAAAA CwACAAEAAAAPAAEDkAYADAAAAAEAAAADAC4AAAAAADIAAQOQBgAYAAAAAQAAAB4APQABAAAA BQAAAFJFOiAAAAAAUwEBA5AGACwAAAABAAAAHgCZCgggBgAAAAAAwAAAAAAAAEYAAAAAOIUA AAEAAAABAAAAAAAAALUCAQOQBgAsAAAAAQAAAB4AmgoIIAYAAAAAAMAAAAAAAABGAAAAADeF AAABAAAAAQAAAAAAAAC1AgEDkAYALAAAAAEAAAAeAJsKCCAGAAAAAADAAAAAAAAARgAAAAA2 hQAAAQAAAAEAAAAAAAAAtQIBA5AGACQAAAABAAAAAwCcCgggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAB7AgEDkAYAJAAAAAEAAAADAJ0KCCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAA AHUCAQOQBgAkAAAAAQAAAAMAngoIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAdQIBA5AG ACQAAAABAAAACwCfCgggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAB8AgEDkAYAJAAAAAEA AAADAKAKCCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAGgCAQOQBgAwAAAAAQAAAB4AoQoI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAApwMBA5AGACQAAAABAAAA AwCiCgggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPMVAADDAwEDkAYAIAAAAAEAAAACAQswAQAA ABAAAADL4SSqjuPTEbD4AAH61PuWJwoBA5AGAAwAAAABAAAAAwCAEP////+QBAEJAAQAAgAA AAAAAAABA5AGAAwAAAABAAAACwAjAAAAAAAvAAEDkAYADAAAAAEAAAALACkAAAAAADUAAQSQ BgDYAQAAAQAAABIAAAAeAAEwAQAAAA0AAAAnaWV0Zi1zbWltZScAAAAAAgH/DwEAAAA7AAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1zbWltZQBTTVRQAGlldGYtc21pbWVAaW1j Lm9yZwAAAwAVDAEAAAADAAAwAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgAaDAEAAAATAAAA TydNYWxsZXksIEJhcnRsZXkAAAACARkMAQAAAD8AAAAAAAAAjVVM0Ow8Ec6B/wgACbEDegEA AAALAAAAAAAAADEdTydNYWxsZXkeMh1CYXJ0bGV5HjUdNjBFVUxPTgAAHgADMAEAAAATAAAA aWV0Zi1zbWltZUBpbWMub3JnAAADAP9fAAAAAAMA/V8BAAAAHgD2XwEAAAALAAAAaWV0Zi1z bWltZQAAAgH3XwEAAAA7AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1zbWltZQBT TVRQAGlldGYtc21pbWVAaW1jLm9yZwAACwAPDgAABIACAQswAQAAABgAAABTTVRQOklFVEYt U01JTUVASU1DLk9SRwADAP4PBgAAAAMAADkAAAAACwBAOgEAEgADAHE6AAAAAAxc --openmail-part-10d68c22-00000001-- Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25435 for ietf-smime-bks; Mon, 14 Feb 2000 15:56:30 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25431 for ; Mon, 14 Feb 2000 15:56:28 -0800 (PST) Message-Id: <4.2.1.20000214155658.03fabec0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 14 Feb 2000 16:01:05 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Problem for public CAs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote: >Instead, in the case of a signed message the From address should be viewed >as secondary, and the certificate contents the primary information. From a security standpoint, this is right. From a UI standpoint, it might not be. Assume I have a different email address in my cert than in the From: header of a message I send you, that your S/MIME client has informed you of that, and you agreed. Now you want to reply to my message. You probably don't want to reply to the email address in my cert, but you might. There are essentially two From vales: the certificate one and the insecure-and-possibly-altered one. >Of course, we have to face the fact that NEITHER the DN nor the RFC822 address >may be particularly relevant or informative. Exactly right. And, no, I'm not proposing a solution here. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA24327 for ietf-smime-bks; Mon, 14 Feb 2000 15:07:45 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA24323 for ; Mon, 14 Feb 2000 15:07:44 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Feb 2000 16:10:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 14 Feb 2000 16:10:05 -0700 From: "Bob Jueneman" To: , Subject: Re: Problem for public CAs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA24324 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This has been a fascinating discussion, in part because of the multi-dimensional aspects to the problem. Let me see if I can summarize some of the different points of view: The first issue raised was one of privacy, and in particular the possibility of spam. This reminds me of two lessons I learned so time ago, rather forcefully, with regard to this space. Back in the PEM days, I was concentrating on the question of how to ensure the legal sufficiency of a digital signature to assure nonrepudiation, and I was suggesting that full name, verified address, and perhaps social security number or driver's license number be included in the certificate. John Gilmore brought me up short by pointing out that we were supposed to be talking about privacy ENHANCED mail. Point taken -- some of this stuff needs to be optional. Then a few years later, I was trying to solve the problem of uniquely identifying someone in a directory, given the presumption at the time that multiple directory service providers (e.g., telcos) might exist and might have overlapping geopolitical boundaries. The answer to this problem, it seemed to me, was to include sufficient disambiguating information, such as street address, assuming that there wouldn't be two people with the same name in the same household. Sharon Boyen gave me another much needed lesson in political correctness by pointing out that many women, in particular, weren't about to list their residence address in a public directory, and many wouldn't even list their given names, preferring to be listed as "M. Smith". Point taken again. If necessary, include meaningless qualifiers such as employeeID for uniqueness. So these are legitimate issues, and I suppose that spam mail is the virtual equivalent of stalking. So I accept the position that says that an e-mail address should not be required, either in the DN or the subjectAltName, although it may be desirable. This bears on the second issue, which I raised at the November meeting, where I pointed out that it was all too easy to manipulate the From address in an e-mail so that the addr-spec portion would match the e-mail address in the certificate, and yet the user-friendly portion of the name could be completely bogus and seriously misleading. I now think that I agree with David Kemp -- this is primarily a man/machine interface issue. In other words, the conventional paradigm of presenting the From address as the primary identification of the sender is WRONG in the case of a digitally signed message, and especially so considering how easily it can be forged or manipulated. Instead, in the case of a signed message the From address should be viewed as secondary, and the certificate contents the primary information. The "contents": in this case should probably include the DN and the subjectAltName, even if it takes an additional line of the GUI display. Of course, we have to face the fact that NEITHER the DN nor the RFC822 address may be particularly relevant or informative. In the case of the DN, at least from the perspective of someone who works for a directory company, the DN is probably going to be whatever it is today, not withstanding the fact that directories today are primary set up for the convenience of the system administrator, and secondly for the benefit of users within the organization, and thirdly if at all for the benefit of users outside of the organization. In my case, for example, my directory name is bjueneman.nsrd.prv.novell (note the "backwards" presentation order), or o=Novell, ou=prv, ou=nsrd, cn=bjueneman. Hardly very helpful to someone on the outside, and certainly not what I would like, but unlikely to change any time soon. Of course, bjueneman@novell.com isn't very helpful either, but better than graybeard123@aol.com. (Public CAs may not have this problem, as they would tend to put "meaningful" names in a directory.) So the ugly fact of the matter is that both DNs and RFC822 names are really the result of legacy systems, and are unlikely to change or to be very helpful. So neither is really satisfactory. My preferred solution? Use an _additional_ subjectAltName to convey the person's "real" name, suitably qualified if desired. And leave the directory DN to the directory administrators, and the RFC822 name to e-mail administrators. Render unto Caesar .... Then in the message display, present the subjectAltName containing a commonName format as primary (if present), the RFC822 address as secondary (if present), and the DN as supplemental information (if present). IN order to assure at least some semblance of uniqueness, either the RFC822 name or the DN MUST be present, and the "real" commonName SHOULD be present. The banner portion of a signed message from me would then be properly displayed as: Signer: Robert R. (Bob) Jueneman [bjueneman@novell.com] [o=Novell, ou=prv, ou=nsrd, cn=bjueneman] The From address, i.e., what the RFC822 From address itself was, would not normally be displayed, except by viewing the message in RFC822 format. I believe that the combination of these three different name forms will be sufficient to adequately disambiguate the sender of a message, and to prevent all sorts of mischief and possible accidents. If this is the display format, I don't care that much about what the name matching rules are, or even whether name matching is done at all. So far, name matching seems to be causing more problems than it solves. Comments? Bob 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 ============================================ 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. 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 ============================================ 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. 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/ 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. 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/ 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 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 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 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 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 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 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 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;... 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 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 > > 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 > > 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 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 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 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