RE: New SMime Capabilities item
"Blake Ramsdell" <BlakeR@deming.com> Thu, 27 May 1999 01:15 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06790 for <smime-archive@odin.ietf.org>; Wed, 26 May 1999 21:15:44 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA06874 for ietf-smime-bks; Wed, 26 May 1999 17:33:01 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA06869 for <ietf-smime@imc.org>; Wed, 26 May 1999 17:33:00 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6); Wed, 26 May 99 17:33:10 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <K60XT4W9>; Wed, 26 May 1999 17:33:10 -0700
Message-ID: <01FF24001403D011AD7B00A024BC53C563E473@mail.deming.com>
From: Blake Ramsdell <BlakeR@deming.com>
To: 'Russ Housley' <housley@spyrus.com>, "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
cc: "Ietf-Smime (E-mail)" <ietf-smime@imc.org>
Subject: RE: New SMime Capabilities item
Date: Wed, 26 May 1999 17:33:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1B524D4C21466-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit
Based on my understanding of Jim's original message, Jim would like to use the OID: sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} That is, within the SMIMECapability structure, the capabilityID would be set to sMIMECapabilitiesVersions, which is a new OID that Jim has proposed under the sMIMECapabilities arc. Blake > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Wednesday, May 26, 1999 2:05 PM > To: Jim Schaad (Exchange) > Cc: Ietf-Smime (E-mail) > Subject: RE: New SMime Capabilities item > > > Jim: > > Yes. MSG-07 includes the follwoing ASN.1. Which OID are you > using for > capabilityID to express S/MIME version preference? > > -- S/MIME Capabilities provides a method of broadcasting the symetric > capabilities > -- understood. Algorithms should be ordered by > preference and grouped > by type > > smimeCapabilities OBJECT IDENTIFIER ::= > {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} > > SMIMECapability ::= SEQUENCE { > capabilityID OBJECT IDENTIFIER, > parameters ANY DEFINED BY capabilityID OPTIONAL } > > SMIMECapabilities ::= SEQUENCE OF SMIMECapability > > > Russ > > At 04:39 PM 5/25/99 -0700, Jim Schaad (Exchange) wrote: > >Russ, > > > >I think the question you are asking is what is the OID for > >sMIMECapabilities? It is already defined as: > >sMIMECapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) > >-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} -- -- [MSG] > > > >If this is not the question you are asking, please be more explicit. > > > >jim > > > >-----Original Message----- > >From: Russ Housley [mailto:housley@spyrus.com] > >Sent: Tuesday, May 25, 1999 1:52 PM > >To: Jim Schaad (Exchange) > >Cc: Ietf-Smime (E-mail) > >Subject: Re: New SMime Capabilities item > > > > > >Jim: > > > >What OID are you using? > > > >Russ > > > > > >At 07:59 PM 5/11/99 -0700, Jim Schaad (Exchange) wrote: > >>Please add the following to the SMimeCapabilities section > of the OIDs > >>document on IMC.ORG. > >> > >>sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} > >>SMIMECapabilitiesVersions ::= SEQUENCE OF INTEGER > >>-- SMime Capabilities Versions holds the sequence of S/MIME V3 > >>specifications > >>-- understood by the client. Currently the only two > items legal > >values > >>are > >>-- v2 (S/MIME version 2) and v3 (S/MIME version 3). > If the item is > >>missing from a > >>-- capabilities list then V2 only should be assumed. > >> > >> > >>The current justification for this is that S/MIME V2 > clients will probably > >>not understand the CMS encrypted data objects. > Specifically receipient > >>infos other than key transport and may not be able to > decrypt the message > >at > >>all if other key managment algorithms are used in the message. > >> > >>jim > >> > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA06874 for ietf-smime-bks; Wed, 26 May 1999 17:33:01 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA06869 for <ietf-smime@imc.org>; Wed, 26 May 1999 17:33:00 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6); Wed, 26 May 99 17:33:10 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <K60XT4W9>; Wed, 26 May 1999 17:33:10 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E473@mail.deming.com> From: "Blake Ramsdell" <BlakeR@deming.com> To: "'Russ Housley'" <housley@spyrus.com>, "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> cc: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> Subject: RE: New SMime Capabilities item Date: Wed, 26 May 1999 17:33:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1B524D4C21466-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Based on my understanding of Jim's original message, Jim would like to use the OID: sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} That is, within the SMIMECapability structure, the capabilityID would be set to sMIMECapabilitiesVersions, which is a new OID that Jim has proposed under the sMIMECapabilities arc. Blake > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Wednesday, May 26, 1999 2:05 PM > To: Jim Schaad (Exchange) > Cc: Ietf-Smime (E-mail) > Subject: RE: New SMime Capabilities item > > > Jim: > > Yes. MSG-07 includes the follwoing ASN.1. Which OID are you > using for > capabilityID to express S/MIME version preference? > > -- S/MIME Capabilities provides a method of broadcasting the symetric > capabilities > -- understood. Algorithms should be ordered by > preference and grouped > by type > > smimeCapabilities OBJECT IDENTIFIER ::= > {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} > > SMIMECapability ::= SEQUENCE { > capabilityID OBJECT IDENTIFIER, > parameters ANY DEFINED BY capabilityID OPTIONAL } > > SMIMECapabilities ::= SEQUENCE OF SMIMECapability > > > Russ > > At 04:39 PM 5/25/99 -0700, Jim Schaad (Exchange) wrote: > >Russ, > > > >I think the question you are asking is what is the OID for > >sMIMECapabilities? It is already defined as: > >sMIMECapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) > >-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} -- -- [MSG] > > > >If this is not the question you are asking, please be more explicit. > > > >jim > > > >-----Original Message----- > >From: Russ Housley [mailto:housley@spyrus.com] > >Sent: Tuesday, May 25, 1999 1:52 PM > >To: Jim Schaad (Exchange) > >Cc: Ietf-Smime (E-mail) > >Subject: Re: New SMime Capabilities item > > > > > >Jim: > > > >What OID are you using? > > > >Russ > > > > > >At 07:59 PM 5/11/99 -0700, Jim Schaad (Exchange) wrote: > >>Please add the following to the SMimeCapabilities section > of the OIDs > >>document on IMC.ORG. > >> > >>sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} > >>SMIMECapabilitiesVersions ::= SEQUENCE OF INTEGER > >>-- SMime Capabilities Versions holds the sequence of S/MIME V3 > >>specifications > >>-- understood by the client. Currently the only two > items legal > >values > >>are > >>-- v2 (S/MIME version 2) and v3 (S/MIME version 3). > If the item is > >>missing from a > >>-- capabilities list then V2 only should be assumed. > >> > >> > >>The current justification for this is that S/MIME V2 > clients will probably > >>not understand the CMS encrypted data objects. > Specifically receipient > >>infos other than key transport and may not be able to > decrypt the message > >at > >>all if other key managment algorithms are used in the message. > >> > >>jim > >> > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA05031 for ietf-smime-bks; Wed, 26 May 1999 14:06:09 -0700 (PDT) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05027 for <ietf-smime@imc.org>; Wed, 26 May 1999 14:06:07 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA17701; Wed, 26 May 1999 14:03:58 -0700 (PDT) Message-Id: <4.1.19990526170311.00a10560@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 26 May 1999 17:05:14 -0400 To: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> From: Russ Housley <housley@spyrus.com> Subject: RE: New SMime Capabilities item Cc: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5F96@DINO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim: Yes. MSG-07 includes the follwoing ASN.1. Which OID are you using for capabilityID to express S/MIME version preference? -- S/MIME Capabilities provides a method of broadcasting the symetric capabilities -- understood. Algorithms should be ordered by preference and grouped by type smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} SMIMECapability ::= SEQUENCE { capabilityID OBJECT IDENTIFIER, parameters ANY DEFINED BY capabilityID OPTIONAL } SMIMECapabilities ::= SEQUENCE OF SMIMECapability Russ At 04:39 PM 5/25/99 -0700, Jim Schaad (Exchange) wrote: >Russ, > >I think the question you are asking is what is the OID for >sMIMECapabilities? It is already defined as: >sMIMECapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) >-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} -- -- [MSG] > >If this is not the question you are asking, please be more explicit. > >jim > >-----Original Message----- >From: Russ Housley [mailto:housley@spyrus.com] >Sent: Tuesday, May 25, 1999 1:52 PM >To: Jim Schaad (Exchange) >Cc: Ietf-Smime (E-mail) >Subject: Re: New SMime Capabilities item > > >Jim: > >What OID are you using? > >Russ > > >At 07:59 PM 5/11/99 -0700, Jim Schaad (Exchange) wrote: >>Please add the following to the SMimeCapabilities section of the OIDs >>document on IMC.ORG. >> >>sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} >>SMIMECapabilitiesVersions ::= SEQUENCE OF INTEGER >>-- SMime Capabilities Versions holds the sequence of S/MIME V3 >>specifications >>-- understood by the client. Currently the only two items legal >values >>are >>-- v2 (S/MIME version 2) and v3 (S/MIME version 3). If the item is >>missing from a >>-- capabilities list then V2 only should be assumed. >> >> >>The current justification for this is that S/MIME V2 clients will probably >>not understand the CMS encrypted data objects. Specifically receipient >>infos other than key transport and may not be able to decrypt the message >at >>all if other key managment algorithms are used in the message. >> >>jim >> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04563 for ietf-smime-bks; Tue, 25 May 1999 16:38:58 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04559 for <ietf-smime@imc.org>; Tue, 25 May 1999 16:38:57 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2580.0) id <K5PL82GM>; Tue, 25 May 1999 16:39:29 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5F96@DINO> From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> To: "'Russ Housley'" <housley@spyrus.com>, "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> Cc: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> Subject: RE: New SMime Capabilities item Date: Tue, 25 May 1999 16:39:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Russ, I think the question you are asking is what is the OID for sMIMECapabilities? It is already defined as: sMIMECapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} -- -- [MSG] If this is not the question you are asking, please be more explicit. jim -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Tuesday, May 25, 1999 1:52 PM To: Jim Schaad (Exchange) Cc: Ietf-Smime (E-mail) Subject: Re: New SMime Capabilities item Jim: What OID are you using? Russ At 07:59 PM 5/11/99 -0700, Jim Schaad (Exchange) wrote: >Please add the following to the SMimeCapabilities section of the OIDs >document on IMC.ORG. > >sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} >SMIMECapabilitiesVersions ::= SEQUENCE OF INTEGER >-- SMime Capabilities Versions holds the sequence of S/MIME V3 >specifications >-- understood by the client. Currently the only two items legal values >are >-- v2 (S/MIME version 2) and v3 (S/MIME version 3). If the item is >missing from a >-- capabilities list then V2 only should be assumed. > > >The current justification for this is that S/MIME V2 clients will probably >not understand the CMS encrypted data objects. Specifically receipient >infos other than key transport and may not be able to decrypt the message at >all if other key managment algorithms are used in the message. > >jim > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28822 for ietf-smime-bks; Tue, 25 May 1999 13:59:55 -0700 (PDT) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28818 for <ietf-smime@imc.org>; Tue, 25 May 1999 13:59:54 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA26094; Tue, 25 May 1999 13:57:52 -0700 (PDT) Message-Id: <4.1.19990525165128.00921680@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 25 May 1999 16:51:54 -0400 To: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> From: Russ Housley <housley@spyrus.com> Subject: Re: New SMime Capabilities item Cc: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5F4A@DINO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim: What OID are you using? Russ At 07:59 PM 5/11/99 -0700, Jim Schaad (Exchange) wrote: >Please add the following to the SMimeCapabilities section of the OIDs >document on IMC.ORG. > >sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} >SMIMECapabilitiesVersions ::= SEQUENCE OF INTEGER >-- SMime Capabilities Versions holds the sequence of S/MIME V3 >specifications >-- understood by the client. Currently the only two items legal values >are >-- v2 (S/MIME version 2) and v3 (S/MIME version 3). If the item is >missing from a >-- capabilities list then V2 only should be assumed. > > >The current justification for this is that S/MIME V2 clients will probably >not understand the CMS encrypted data objects. Specifically receipient >infos other than key transport and may not be able to decrypt the message at >all if other key managment algorithms are used in the message. > >jim > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA14895 for ietf-smime-bks; Tue, 25 May 1999 07:01:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14891 for <ietf-smime@imc.org>; Tue, 25 May 1999 07:01:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15781; Tue, 25 May 1999 10:01:21 -0400 (EDT) Message-Id: <199905251401.KAA15781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-cmskea-01.txt Date: Tue, 25 May 1999 10:01:21 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-01.txt Pages : 10 Date : 24-May-99 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cmskea-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmskea-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-cmskea-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990524125734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmskea-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmskea-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990524125734.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17593 for ietf-smime-bks; Mon, 24 May 1999 16:30:55 -0700 (PDT) Received: from relay.gw.tislabs.com (firewall-user@relay.gw.tislabs.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17584 for <ietf-smime@imc.org>; Mon, 24 May 1999 16:30:53 -0700 (PDT) Received: by relay.gw.tislabs.com; id TAA28741; Mon, 24 May 1999 19:45:15 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma028728; Mon, 24 May 99 19:44:18 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.1/8.9.1) id TAA10008 for ietf-smime@imc.org; Mon, 24 May 1999 19:26:52 -0400 (EDT) Date: Mon, 24 May 1999 19:26:52 -0400 (EDT) From: "David M. Balenson" <balenson@tislabs.com> Message-Id: <199905242326.TAA10008@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: REMINDER: CFP: ISOC Year 2000 Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> C A L L F O R P A P E R S The Internet Society Year 2000 Network and Distributed System Security Symposium (NDSS 2000) Catamaran Resort Hotel, San Diego, California February 2-4, 2000 IMPORTANT DATES: Paper and panel submissions due: June 16, 1999 Author notification: August 17, 1999 Final versions of papers and panels due: October 15, 1999 GOAL: This symposium aims to foster information exchange among researchers and practitioners of network and distributed system security services. The intended audience includes those who are interested in practical aspects of network and distributed system security, with the focus on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce, e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and, of course, the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g. interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Integrating security services with system and application security facilities and protocols, e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing. * Security for emerging technologies -- sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures * Network Perimeter Controls: firewalls, packet filters, application gateways. BEST PAPER AWARD: A best paper award will be introduced at NDSS 2000. This award will be presented at the symposium to the authors of the best paper to be selected by the program committee. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Gene Tsudik, USC / Information Sciences Institute Avi Rubin, AT&T Labs - Research TUTORIAL CHAIR: Doug Maughan, NSA / DARPA PROGRAM COMMITTEE: Bill Cheswick, Lucent Bell Labs Marc Dacier, IBM Research Zurich Jim Ellis, CMU / CERT Carl Ellison, Intel Ed Felten, Princeton Virgil Gligor, UMD College Park Thomas Hardjono, Bay Networks/Nortel Cynthia Irvine, Naval Postgraduate School Charlie Kaufman, Iris Associates Dave Kormann, AT&T Labs - Research Hugo Krawczyk, Technion and IBM Carl Landwehr, Naval Research Lab Doug Maughan, NSA / DARPA Gary McGraw, Reliable Software Technologies Sandra Murphy, TIS Labs at Network Associates Clifford Neuman, USC / Information Sciences Institute Paul Van Oorschot, Entrust Sami Saydjari, DARPA ISO David Wagner, UC Berkeley Bennet Yee, UC San Diego LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: John Kochmar, SEI PUBLICITY CHAIR: David Balenson, TIS Labs at Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society REGISTRATIONS CHAIR Beth Strait, Internet Society SUBMISSIONS: The committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may -- at the discretion of the panel chair -- include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by June 16, 1999, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. All submissions and program related correspondence (only) should be directed to the program chair: Gene Tsudik USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292 Email: ndss00@isi.edu TEL: +1 (310) 822-1511 ext 329 FAX: +1 (310) 823-6714 Dates, final call for papers, advance program, and registration information will be available soon at the URL: httl//www.isoc.org/ndss2000. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by August 17, 1999. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 15, 1999. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA27948 for ietf-smime-bks; Mon, 24 May 1999 10:44:00 -0700 (PDT) Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27943 for <ietf-smime@imc.org>; Mon, 24 May 1999 10:43:59 -0700 (PDT) Received: from [193.237.150.98] (helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 10lym4-0001Ji-0A for ietf-smime@imc.org; Mon, 24 May 1999 17:44:31 +0000 Message-ID: <3749798D.8697DFF2@celocom.com> Date: Mon, 24 May 1999 17:08:45 +0100 From: Dr Stephen Henson <drh@celocom.com> Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win95; U) MIME-Version: 1.0 To: "ietf-smime@imc.org" <ietf-smime@imc.org> Subject: Re: X9.42 comments. References: <37470D4B.727B13FF@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Couple of additional comments all about section 2.2.1.1 [note I've retained the original X9.42 text even in places where I've claimed other problems in a previous message]. Firstly the algorithm for calculating 'q' in step 4 will produce a value of 'q' with lots of zero bits if m is not a multiple of 160. For example if m=319 it will have 158 zero bits. This can be readily fixed by setting m' = (m + 159)/160 in step 3 and in step 5: q = U mod 2^m initially and then set the most and least signinificant bits as before. The second issue may not be a problem as such. The use of SEED doesn't quite follow the FIPS-186 usage. Let me explain... At several points FIPS-186 uses SHA[(SEED+k)mod 2^g] for the generation of prime number candidates. The way it uses it obeys two rules. 1. Each value of k is used only once. 2. The order of use is such that each value of k is used in sequence. (1) may have some cryptographic reason to ensure the same pseudo random data is not re-used. (2) makes implementation particularly easy: an implementer only needs retain a copy of SEED+k and increment it every time it is used. This property is not immediately apparent because of the way FIPS-186 is written but it goes something like this: All this refers to Appendix 2.2 FIPS-186: Step 2. first uses SEED. It makes use of SEED and SEED+1 to calculate U (and ultimately a candidate q). If q is not prime a new SEED is tried otherwise p is constructed from: Vk = SHA[(SEED + offset + k) mod 2^g ]. For values of k = 0,...,n, and offset initially is 2. This means that SEED+2, SEED+3, ... SEED+n+2 are used to ultimately build a candidate p. If this is not successful (n+1) is added to offset making it n+3 and each Vk calculated again. As can be seen the value of SEED is incremented on each use. The generalisation in X9.42 obeys neither rule if m' > 1. In this case: 4. for i = 0 to m' - 1 U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] * 2^(160 * i) This ends up using SEED and SEED+m'+1 (which is compatible with FIPS186 if m'=1) however if m'=3 say this uses SEED, SEED+3, SEED+1, SEED+4, SEED+2, SEED+5 Then when we get to step 9 we end up using SEED+2, SEED+3,... and so on. This ends up re-using the same data and as is apparent this is not in order. If the algorithm used is made to be compatible with something else then not much can be done. If we do have some control over it and the same rules as FIPS-186 are desired then these changes should work: Step 4. 4. for i = 0 to m' - 1 U = U + SHA[SEED + 2*i] XOR SHA[(SEED + 2*i + 1) mod 2^160] * 2^(160 * i) Step 8. Let counter=0 and offset = 2*m' Assuming I haven't made some stupid slip this should end up incrementing SEED each time and only using each value once. As before this retains compatability with FIPS-186 if m=160 (m'=1). Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA25739 for ietf-smime-bks; Mon, 24 May 1999 07:46:51 -0700 (PDT) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25735 for <ietf-smime@imc.org>; Mon, 24 May 1999 07:46:50 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA06087; Mon, 24 May 1999 07:44:42 -0700 (PDT) Message-Id: <4.1.19990521140625.00911c40@mail.spyrus.com> Message-Id: <4.1.19990521140625.00911c40@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 24 May 1999 10:45:37 -0400 To: bjueneman@novell.com From: Russ Housley <housley@spyrus.com> Subject: Re: Issues with S/MIME Message Specification Cc: ietf-smime@imc.org, jis@mit.edu, MLeech@nortel.ca In-Reply-To: <006701bea15d$124b2e60$4dd44189@provo.novell.com> References: <199905171126.HAA17249@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Bob: In CMS Section 12.3.2, RSA Key Management is a "should" implement algorithm. As a result of an editorial error, in CMS Section 12.2, RSA Signature is a "may" implement algorithm. I thought that they had the same "should" status. This would be consistent with the MSG document. We went through great pains to include support many, many algorithms in CMS. The "must" implement algorithms to provide a set of interoperable strong algorithms. The "should" implement algorithms provide backward compatibility with S/MIMEv2. Any other algorithm is considered a "may" implement algorithm. RSA with OAEP falls into this "may" implement category. The IETF consistently includes strong algorithms in standards. If you wish to discuss this policy, please discuss it in a broader context (not just S/MIME) with the IETF Security Area Directors (Jeff Schiller and Marcus Leech). I have CCed them on this e-mail message, so you have their addresses. I do not consider this an approprate topic for the S/MIME mail list. I wish you had raised this inconsistency during CMS and MSG Last Call. The IESG has approved these documents. I hope you will raise this topic again when the documents are considered for Draft Standard status. Russ S/MIME WG Chair & CMS Document Editor At 12:34 PM 5/18/99 -0600, Robert R. Jueneman wrote: >I sincerely regret not having had sufficient time to review the S/MIME v3 >specs in detail during last call and prior to their moving to Proposed >Standard, but I believe that there are several changes that absolutely >must be made before they can progress to final Standard. > >Regarding the S/MIME Version 3 Message Specification, >draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs >regarding specific cryptographic algorithms should be removed from this >document, and contained only in the Cryptographic Message Syntax document. >I can see no reason at all why such things should be specified twice -- it >just makes conformance checking all that much more difficult. An example >of this kind of difficulty is para 2.2 of the S/MIME Message >Specification, which says that sending and receiving agents SHOULD support >rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says >that CMS implementations "may" support RSA. Neither mentions RSA with >OAEP. > >This affects section 2.1, 2.2, and 2.3, and most emphatically section 2.7, >"ContentEncryption AlgorithmIdentifier", and 2.7.1.3 "Rule 3, Unknown >Capabilities, Unknown Version of S/MIME." > >Without getting into international politics, at the present time >triple-DES is not exportable from the US, at the very least, and may very >well not be importable into some other countries. Specifying that S/MIME >agents MUST implement triple-DES therefore presents a vendor with Hobson's >choice -- they can either chose not to be compliant with the RFC, or they >can chose not to export their product. Unfortunately, that is no choice >at all -- any sane US vendor will choose not to be compliant with the RFC, >rather than lose perhaps 50% of their market. The only purpose such a >red-flag-in-front-of-the-bull statement serves, therefore, is a political >one, and one that will merely lower the credibility of the IETF and the >IESG in the vendor and business community. At most the requirement should >be SHOULD. > >The second part of 2.7 specifies that receiving agents SHOULD support >RC2/40 "or a compatible algorithm at a key size of 40 bits..." This >recommendation suffers from two major problems, in my view. First, it is >LESS secure than 56-bit DES, which is now acceptable world-wide (with >perhaps one or two minor exceptions -- not quite clear) for data >encryption. And second, it is a proprietary, trade-secret algorithm. Not >only is that contrary to the general direction of the IETF in not >mandating proprietary algorithms, but the fact that it is a trade secret >(not withstanding the fact that it has been reverse engineered) means that >there has not been adequate attention paid to its security in the academic >cryptanalytic community. RC2 of any size may well be worth considering >for support, and might deserve RECOMMENDED status, but that should be up >to the vendor. If RC2 is required for backwards compatibility with S/MIME >v2, then a paragraph noting that fact would be appropriate, as was >provided as the last paragraph under 2.3 ("Note that S/MIME v2 clients are >only capable of decrypting content encryption keys using the rsaEncryption >algorithm."). > >(I am taking this position with no lack of respect for Ron Rivest, whom I >consider a very able cryptographer. But I would take that position if God >Herself had invented but not published some particular algorithm.) > >With respect to 2.7.1.3, there are two problems. First, it mandates >triple-DES, which very well may not be available at to the recipient, and >secondly, it recommends as a fall back position the use of the >trade-secret RC2/40. Both statements should be removed. The CMS >specification should then develop a list of algorithms in rough order of >strength, to be used for such negotiations as required. > >Finally, somewhere in these documents there is a statement regarding the >advisability of including the content encryption key encrypted in the >originator's public key, but despite rereading the documents multiple >times I can't find that text again. As I recall, the text said that this >SHOULD be done. I would argue that this should be changed to MUST, for I >can't imagine a situation where the originator of an encrypted message >would not want to be able to read his own message, for example in an >outgoing or Sent-Mail queue. He might need to be able to decrypted, and >even retract it in order to resend it with modifications. It would not be >reasonable to rely on the originator to bcc herself to gain this >capability -- it ought to be required by the spec. > >I will be addressing my concerns with the CMS specification in a >subsequent message. > >Bob > >--------------------------- >Robert R. Jueneman >Novell, Inc. > >(See digital signature DISCLAIMER in attached vCard) > >>-----Original Message----- >>From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On >>Behalf Of The IESG >>Sent: Monday, May 17, 1999 5:26 AM >>To: IETF-Announce: ; >>Cc: RFC Editor; Internet Architecture Board; ietf-smime@imc.org >>Subject: Protocol Action: Cryptographic Message Syntax to Proposed >>Standard >> >> >> >> >>The IESG has approved publication of the following Internet-Drafts as >>Proposed Standards: >> >> o Cryptographic Message Syntax <draft-ietf-smime-cms-13.txt> >> o Diffie-Hellman Key Agreement Method <draft-ietf-smime-x942-07.txt> >> o S/MIME Version 3 Certificate Handling <draft-ietf-smime-cert-08.txt> >> o S/MIME Version 3 Message Specification <draft-ietf-smime-msg-08.txt> >> o Enhanced Security Services for S/MIME <draft-ietf-smime-ess-12.txt> >> >>These documents are the product of the S/MIME Mail Security Working >Group. >>The IESG contact persons are Jeffrey Schiller and Marcus Leech. >> >> >>Technical Summary >> >>These documents describe Version 3 of S/MIME (Secure/Multipurpose >>Internet Mail Extensions). S/MIME provides for the secure >>communication of MIME Objects, providing Authentication, Integrity and >>Confidentiality protection. It can be used wherever MIME is used, as >>it is fully conformant with the general MIME specifications. The >>documents here provide for the basic message syntax and semantics as >>well as the certificate and key management infrastructure >>required. This work is coordinated and builds upon the work of the >>IETF X.509 Public Key Infrastructure Working Group (PKIX). >> >>In addition to the basic security services mentioned above, several >>optional services are described. These include signed receipt >>handling, security labeling of objects, secure mailing lists and >>signing certificates. >> >>Working Group Summary >> >>The working group came to consensus on the work described here. A lot >>of people contributed thoughtful, useful and constructive comments >>during the review periods which resulted in further improvements >>reflected in these documents. >> >>Jeffrey I. Schiller reviewed the specification for IESG. >> >> > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00679 for ietf-smime-bks; Sat, 22 May 1999 13:06:50 -0700 (PDT) Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00673 for <ietf-smime@imc.org>; Sat, 22 May 1999 13:06:48 -0700 (PDT) Received: from [193.237.150.98] (helo=celocom.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 10lI30-000Mtk-0C for ietf-smime@imc.org; Sat, 22 May 1999 20:07:06 +0000 Message-ID: <37470D4B.727B13FF@celocom.com> Date: Sat, 22 May 1999 21:02:19 +0100 From: Dr Stephen Henson <drh@celocom.com> Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win95; U) MIME-Version: 1.0 To: "ietf-smime@imc.org" <ietf-smime@imc.org> Subject: X9.42 comments. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> As an initial step to implementing S/MIME v3 I started examining X9.42 at length with a view to implementing DH certificates support (which may well end up in OpenSSL at some point). Previously I'd only verified the KEK generation examples and not started on a full implementation. I assume there are no examples available yet? By examples I mean examples of key pairs, parameters, SEED values and shared secrets that is: not just the KEK generation stuff which is already present. A few things have cropped up: maybe some more will crop up during (attempted) implementation. My appologies in advance for mentioning them at this late stage, but there are certain things that only crop up when you try to implement the algorithm. All in section 2.2.1.1 Firstly at the start: >Let L - 1 = n*m + b where both b and n are integers and 0 <= b < 160. For arbitrary values of L and m this cannot always be satisfied. I'm not 100% sure but I think this should be: "Let L - 1 = n*160 + b where both b and n are integers and 0 <= b < 160" which is the same as FIPS186. The reason being 'n' and 'b' are used to generate 'W' (and ultimately p) by adding together 160 bit "chunks" in step 10. The "160" here comes from the size of an SHA digest. Then step 4: > 4. for i = 0 to m' - 1 > > U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] * > 2^(160 * i) > > Note that for m=160, this reduces to the algorithm of [FIPS-186] > > U = SHA[SEED] XOR SHA[(SEED+1) mod 2^160 ]." Presumably SHA refers to SHA-1? My copy of FIPS-186 has (mod 2^g) in it (g is size of seed in bits) not (mod 2^160). As things stand (mod 2^160) is effectively throwing away the first g-160 bits of SEED, whereas (mod 2^g) is discarding any carry (which is admittedly rather unlikely). Anyway for completeness should the carry be discarded on the first part as well? So the complete thing would read: U = U + SHA[(SEED + i)mod 2^g] XOR SHA[(SEED + m' + i) mod 2^g] * 2^(160 * i) Otherwise there is a very unlikely posibility that SEED + i will be longer than SEED (but this case is excluded in the second SHA anyway). Couple more things. The use of g for two separate things is a little confusing: size of SEED in bits and one of the DH parameters. Though FIPS186 does this as well. Presumably the size of SEED in bits must be a multiple of 8? Since SEED is represented as a BIT STRING (see PKIX) this need not be so. I assume the "no trailing zero bits" DER encoding rule doesn't apply here: otherwise there will be possible ambiguity. Finally step 10 seems a bit garbled: there are a few ^ missing. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25832 for ietf-smime-bks; Wed, 19 May 1999 11:11:33 -0700 (PDT) Received: from fax.imc.org (root@[207.94.139.160]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25821 for <ietf-smime@imc.org>; Wed, 19 May 1999 11:11:31 -0700 (PDT) Received: from aum (ip161.imc.org [207.94.139.161]) by fax.imc.org (8.9.3/8.9.0) with ESMTP id LAA19142 for <ietf-smime@imc.org>; Wed, 19 May 1999 11:10:37 -0700 (PDT) Message-Id: <4.2.0.44.19990519110622.021720d0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.44 (Beta) Date: Wed, 19 May 1999 11:11:35 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: RE: Issues with S/MIME Message Specification In-Reply-To: <92712564910974@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Can we PLEASE drop this thread? It makes no sense for a couple of reasons: - The spec already has passed the IESG. Done. If you want to debate this, you have to issue a new spec and argue about that. (I'm not suggesting this, just saying that is what you have to do.) - When we chartered this WG, we were told we had to use strong crypto. Period. We agreed. - The arguments that "people won't produce this" have already been proven to be false in the marketplace already. I will say again that I believe that it was inappropriate for this tread to be started **after** the specs were approved by the IESG and **years** after the discussion had gotten consensus in the WG. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23236 for ietf-smime-bks; Wed, 19 May 1999 08:43:36 -0700 (PDT) Received: from esmerelda.ve3tla.ampr.org (root@esmerelda.ve3tla.ampr.org [209.47.237.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23232 for <ietf-smime@imc.org>; Wed, 19 May 1999 08:43:34 -0700 (PDT) Received: from penelope.ve3tla.ampr.org (24.64.156.6.on.wave.home.com [24.64.156.6]) by esmerelda.ve3tla.ampr.org (8.8.7/8.8.7) with ESMTP id LAA01866; Wed, 19 May 1999 11:43:37 -0400 Received: from penelope.ve3tla.ampr.org (chk@localhost [127.0.0.1]) by penelope.ve3tla.ampr.org (8.8.7/8.8.7) with ESMTP id LAA09357; Wed, 19 May 1999 11:43:33 -0400 Message-Id: <199905191543.LAA09357@penelope.ve3tla.ampr.org> To: bartley.o'malley@citicorp.com cc: ietf-smime@imc.org Subject: Export Restrictions (was Re: Issues with S/MIME Message Specification) References: <199905191326.JAA21761@egate3.citicorp.com> In-reply-to: Your message of "Wed, 19 May 1999 14:27:03 +0100". <199905191326.JAA21761@egate3.citicorp.com> From: "C. Harald Koch" <chk@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9352.927128612.1@penelope.ve3tla.ampr.org> Date: Wed, 19 May 1999 11:43:32 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> In message <199905191326.JAA21761@egate3.citicorp.com>, bartley.o'malley@citicorp.com writes: > Creating a world-wide standard which significant > portions of the world are unable to comply with is pointless. I can't believe we're having this discussion *again* in the Security Area. Regardless: I strongly dispute your claim of "significant portions of the world". Countries with import or use restrictions on cryptography are rare; even France has backed down on that one. Whether you like it or not, American companies and their government's export restrictions are irrelevant. There are numerous examples of non-US organisations picking up the slack, and their are numerous examples of American companies getting around the restrictions. Two examples would be RSA's new office in Australia, and the Fortify program for Netscape Communicator. IETF standards will outlive government restrictions on cryptography, and should not short-sightedly cater to them. Last time I checked, this was also the opinion of the IESG. -- C. Harald Koch <chk@pobox.com> "It takes a child to raze a village." -Michael T. Fry Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22638 for ietf-smime-bks; Wed, 19 May 1999 07:54:15 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22632 for <ietf-smime@imc.org>; Wed, 19 May 1999 07:54:13 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id CAA07900; Thu, 20 May 1999 02:54:09 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92712564910974>; Thu, 20 May 1999 02:54:09 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: aferguso@enternet.com.au, ietf-smime@imc.org Subject: RE: Issues with S/MIME Message Specification Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 20 May 1999 02:54:09 (NZST) Message-ID: <92712564910974@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Andrew Ferguson <aferguso@enternet.com.au> writes: >I believe it should say SHOULD (definitly not MUST) and perhaps to be precise >refer to the newly ratified Wassenaar agreement, eg : "except where >prohibited under the Wassenaar Agreement" which will cover export and import >into and from various countries. Adding this wouldn't make much sense, Wassenaar isn't a treaty or agreement but an arrangement, and has no binding force on anyone, so Wassenaar itself doesn't prohibit anything. As the Wassenaar articles say, implementation is purely a matter of national legislation and policy. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21813 for ietf-smime-bks; Wed, 19 May 1999 06:47:31 -0700 (PDT) Received: from egate3.citicorp.com ([192.193.195.192]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA21808 for <ietf-smime@imc.org>; Wed, 19 May 1999 06:47:26 -0700 (PDT) From: bartley.o'malley@citicorp.com Received: by egate3.citicorp.com id JAA21761 (InterLock SMTP Gateway 4.2 for ietf-smime@imc.org); Wed, 19 May 1999 09:26:24 -0400 Message-Id: <199905191326.JAA21761@egate3.citicorp.com> Received: by egate3.citicorp.com (Protected-side Proxy Mail Agent-3); Wed, 19 May 1999 09:26:24 -0400 Received: by egate3.citicorp.com (Protected-side Proxy Mail Agent-2); Wed, 19 May 1999 09:26:24 -0400 Received: by egate3.citicorp.com (Protected-side Proxy Mail Agent-1); Wed, 19 May 1999 09:26:24 -0400 Date: Wed, 19 May 1999 14:27:03 +0100 Subject: RE: Re: Issues with S/MIME Message Specification To: ietf-smime@imc.org X-Mailer: Worldtalk (4.1.1-p14)/MIME Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> I was under the impression that the purpose of defining a standard was to create a specification which people could follow, independently, to produce interoperable products. Creating a world-wide standard which significant portions of the world are unable to comply with is pointless. We are likely to end up, unofficially, with S/Mime(Strong) and S/Mime(Weak), people are just as likely to be frightened by incompatible varying implementations. The whole idea of MUST is to produce a minimum level of interoperability which EVERYONE can adhere to. SHOULD is there to enable those who have the time/money/inclination/authorisation to achieve higher levels of interoperability and security, with MAY specifying the very highest levels. I believe Enzo is correct in his statement that minimum levels of compliance cannot be specified as SHOULD. However, the strongest level of encryption available, 3DES, ought not to be listed in the minimum compliance requirements. Bob Jueneman's objection(since withdrawn) to the trade secret RC2 algorithm is eminently reasonable. The IETF's refusal to use proprietary or restricted material is equally sensible. The problem we have is that the US government maintains a "proprietary" claim over 3DES in the form of export restrictions, as do many other governments regarding encryption algorithms. Until we have all lobbied our respective governments to remove these restrictions we MUST operate sensibly within them. 3DES ought to be listed as SHOULD and those who can write/export 3DES SHOULD and those who can't....can't. I believe that section 2.7.1 provides adequate recommendation and controls to enable the strongest available algorithm to be selected. There is a requirement for approval to use weak encryption prior to sending each weakly encrypted message, so there is little chance of one sending insecure messages by accident. Bartley O'Malley UK -----Original Message----- From: owner-ietf-smime(a)imc.org Sent: Wednesday, May 19, 1999 12:26 PM To: ietf-smime(a)imc.org; aferguso(a)enternet.com.au Cc: em(a)who.net; cryptography(a)c2.net Subject: Re: Issues with S/MIME Message Specification I disagree totally with the idea of making strong encryption optional. First of all, one cannot use SHOULD on matters of minimal compliance. Second, a standard cannot be defined conditionally to the local laws: at most, the development process of actual products, and their sales, may have to depend on them. Third, allowing exportable (i.e., totally useless) encryption in algorithms and protocols required for minimal compliance will result in nobody buying products based on that standard, opting instead for, e.g., OpenPGP, or even de-facto standards. The right ways to avoid export restriction are: a) Lobby your governments, letting them know that such stupid laws will result in job losses and hamper the development of e-commerce, and have the laws changed. This often works: France is a recent example. b) If a) fails, develop products in places where those laws do not apply. Deceiving the public with products which are defined "secure" (what does the "S" in "S/MIME" stand for?), and are not, is not only unethical, but ultimately will harm the sales and the vendor's bottom line. IETF should steer clear from endorsing such ill-advised practices. Enzo ----- Original Message ----- From: Andrew Ferguson <aferguso@enternet.com.au> To: <ietf-smime@imc.org> Sent: Wednesday, May 19, 1999 5:47 PM Subject: RE: Issues with S/MIME Message Specification > Andrew, Robert, All, > As a watcher, but not up to now an active participant in this debate on the > matter of Issues with the S/MIME Message specification, I believe it > should say SHOULD (definitly not MUST) and perhaps to be precise refer to > the newly ratified Wassenaar agreement, eg : "except where prohibited > under the Wassenaar Agreement" which will cover export and import into and > from various countries. This will in effect provide a neat get out clause > covering both issues. The reality as Bob points out below we Aussies are > not necessarily worried about the US Export laws, but of course Australia > now exports our own crypto developed products so we would also affected by > the statement MUST. > > > Anyway thats my contribution. > > At 10:34 19/05/99 , Robert R. Jueneman wrote: > >>>With respect to the issue of bcc'ing the originator on an encrypted > >>>message, although I suppose it is possible that the originator doesn't > >>>have a public encryption key, this seems mildly unlikely, so I am more > >>>inclined to agree with William Whyte's comment. > >> > >>I'm not sure that the My Esteemed Colleague's comment was anything > >>more than a point of information. There will be situations when an > >>application should include an originator key, but there are also counter > >>examples. Locking a MUST into the standard is unnecessary, particularly > >>since there's no compelling interoperability or security issue. > >> > >>>I wish I could find where I read that statement -- I thought it was in = > >>>one of the RFC's, but I can't find it. > >> > >>draft-ietf-smime-msg-08.txt, section 3.3 > > > >Thanks. I knew I had read it, but couldn't find it. > > > >Now that I see the exact text once again, and given the apparent > >request by some to NOT keep a copy, I can live with SHOULD. > > > >> > >>Also, it should be noted that switching from MUST RC4 to MUST tripleDES > >>was the very first thing the ietf-smime group did, back 2 years ago. > >>There was a lot of discussion back then, all of it available on the IMC > >>mail archive. Not intended as a brush-off: there was a lot of relevant > >>debate. > >> > >I can certainly understand preferring triple-DES vs. RC4, but I'm still not > >thrilled about having a firm specification that it is illegal for me to > >comply with > >if I hope to export the product. I can fully understand that perhaps you > >might not share my concern on this point--neither do the Canadians, the > >Australians, or others! :-) > > > >But what would your position be if the situation were reversed, or if, for > >example, you could not export such a product to the US, and you might > >face losing half of your market as a result? > > > >I confess I haven't looked up the precise definition of MUST. Is there > >perhaps some face saving wriggle-room that says something like > >"except where prohibited by law or regulations"? > > > >Not being compliant with the RFC doesn't bother me all that much-- > >there aren't any IETF police, and procurements that require > >compatibility just won't get it, except for US/Canada domestic and > >certain industry sectors outside the US. > > > >What concerns me more is the assumption that because the > >standard says MUST, there is a presumption that it WILL > >actually be so, and that interoperability decisions about > >what kind of algorithms can be used can assume this as a default. > >T'ain't so, unfortunately, unless all of the US vendors roll over and > >play dead in the European and Asian markets. And that isn't > >going to happen. > > > >Regards, > > > >Bob > > > > > > > ------ > Software Agencies Australia Pty Ltd > 1 Huntingdale Road > Burwood, > Victoria 3125 > Australia > ACN 078 025 813 > Tel: +61-3-9808-0522 > Fax: +61-3-9888-6019 > Mobile: +61-41-222-3940 > Email: Andrew.Ferguson@software-aus.com.au > URL: www.software-aus.com.au > Your Business Partner in Electronic and Internet Commerce > > << File: UnXhrds.txt >> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20291 for ietf-smime-bks; Wed, 19 May 1999 04:35:11 -0700 (PDT) Received: from puma.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20285 for <ietf-smime@imc.org>; Wed, 19 May 1999 04:35:09 -0700 (PDT) Received: by puma.baltimore.ie; id NAA15347; Wed, 19 May 1999 13:08:35 +0100 (GMT/IST) Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma015320; Wed, 19 May 99 13:08:04 +0100 Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.5) with ESMTP id MAA13026; Wed, 19 May 1999 12:34:42 +0100 Message-Id: <199905191134.MAA13026@ocelot.baltimore.ie> To: ietf-smime@imc.org Cc: bjueneman@novell.com Subject: Re: Issues with S/MIME Message Specification In-Reply-To: Your message of "Tue, 18 May 1999 18:34:01 MDT." <00d201bea18f$4a986850$4dd44189@provo.novell.com> Date: Wed, 19 May 1999 12:34:42 +0100 From: Andrew Farrell <afarrell@baltimore.ie> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Robert Jueneman writes: >>Also, it should be noted that switching from MUST RC4 to MUST tripleDES >>was the very first thing the ietf-smime group did, back 2 years ago. >>There was a lot of discussion back then, all of it available on the IMC >>mail archive. Not intended as a brush-off: there was a lot of relevant >>debate. >I can certainly understand preferring triple-DES vs. RC4, but I'm still >not thrilled about having a firm specification that it is illegal for >me to comply with if I hope to export the product. I can fully >understand that perhaps you might not share my concern on this >point--neither do the Canadians, the Australians, or others! :-) >But what would your position be if the situation were reversed, or if, >for example, you could not export such a product to the US, and you >might face losing half of your market as a result? I'm not here as a representative of my company, but I suspect we'd take half a market rather than none, and we'd be lobbying our government continuously to do something against this blatant crippling of Irish software. As for an actual employee of an actual US company, Ned Freed put it better than I could: http://www.imc.org/ietf-smime/mail-archive/msg00169.html >I confess I haven't looked up the precise definition of MUST. Is there >perhaps some face saving wriggle-room that says something like >"except where prohibited by law or regulations"? MUST is from RFC 2119, and there's no wriggle-room there ("This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification"). There can't be, in fairness. It's an interoperability thing. All S/MIME has to do is produce something that's secure and interoperable. If there's an option that's secure and interoperable and can be exported by anyone from the US, it hasn't been presented, as far as I know. >What concerns me more is the assumption that because the >standard says MUST, there is a presumption that it WILL >actually be so, and that interoperability decisions about >what kind of algorithms can be used can assume this as a default. >T'ain't so, unfortunately, unless all of the US vendors roll over and >play dead in the European and Asian markets. And that isn't >going to happen. >From listening too much to our marketing people, I get the impression that US vendors that can't export strong cryptography are doing just that in those markets. But I'd rather hear something from one of the US companies. Jim? Blake? Someone from Netscape (who is someone from Netscape these days)? Also, it cuts both ways. If the specs have a MUST for weak crypto (and they have to have a MUST, for interoperability), then people out here will get requirements that they produce S/MIME that cannot default to weak crypto, and they'll break interoperability. Not that any of this is the business of the IETF. The IETF's business is making the best standards. >Regards, >Bob Andrew. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20178 for ietf-smime-bks; Wed, 19 May 1999 04:26:25 -0700 (PDT) Received: from pop03.globecomm.net (pop03.globecomm.net [206.253.130.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20174 for <ietf-smime@imc.org>; Wed, 19 May 1999 04:26:24 -0700 (PDT) Received: from home (du0004.ima.net [202.75.0.133]) by pop03.globecomm.net (8.9.0/8.8.0) with SMTP id HAA18938; Wed, 19 May 1999 07:26:26 -0400 (EDT) Message-ID: <006401bea1ea$70075320$85004bca@home> From: "Enzo Michelangeli" <em@who.net> To: <ietf-smime@imc.org>, "Andrew Ferguson" <aferguso@enternet.com.au> Cc: <cryptography@c2.net> References: <4.1.19990519194705.009a9400@mail.enternet.com.au> Subject: Re: Issues with S/MIME Message Specification Date: Wed, 19 May 1999 19:24:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> I disagree totally with the idea of making strong encryption optional. First of all, one cannot use SHOULD on matters of minimal compliance. Second, a standard cannot be defined conditionally to the local laws: at most, the development process of actual products, and their sales, may have to depend on them. Third, allowing exportable (i.e., totally useless) encryption in algorithms and protocols required for minimal compliance will result in nobody buying products based on that standard, opting instead for, e.g., OpenPGP, or even de-facto standards. The right ways to avoid export restriction are: a) Lobby your governments, letting them know that such stupid laws will result in job losses and hamper the development of e-commerce, and have the laws changed. This often works: France is a recent example. b) If a) fails, develop products in places where those laws do not apply. Deceiving the public with products which are defined "secure" (what does the "S" in "S/MIME" stand for?), and are not, is not only unethical, but ultimately will harm the sales and the vendor's bottom line. IETF should steer clear from endorsing such ill-advised practices. Enzo ----- Original Message ----- From: Andrew Ferguson <aferguso@enternet.com.au> To: <ietf-smime@imc.org> Sent: Wednesday, May 19, 1999 5:47 PM Subject: RE: Issues with S/MIME Message Specification > Andrew, Robert, All, > As a watcher, but not up to now an active participant in this debate on the > matter of Issues with the S/MIME Message specification, I believe it > should say SHOULD (definitly not MUST) and perhaps to be precise refer to > the newly ratified Wassenaar agreement, eg : "except where prohibited > under the Wassenaar Agreement" which will cover export and import into and > from various countries. This will in effect provide a neat get out clause > covering both issues. The reality as Bob points out below we Aussies are > not necessarily worried about the US Export laws, but of course Australia > now exports our own crypto developed products so we would also affected by > the statement MUST. > > > Anyway thats my contribution. > > At 10:34 19/05/99 , Robert R. Jueneman wrote: > >>>With respect to the issue of bcc'ing the originator on an encrypted > >>>message, although I suppose it is possible that the originator doesn't > >>>have a public encryption key, this seems mildly unlikely, so I am more > >>>inclined to agree with William Whyte's comment. > >> > >>I'm not sure that the My Esteemed Colleague's comment was anything > >>more than a point of information. There will be situations when an > >>application should include an originator key, but there are also counter > >>examples. Locking a MUST into the standard is unnecessary, particularly > >>since there's no compelling interoperability or security issue. > >> > >>>I wish I could find where I read that statement -- I thought it was in = > >>>one of the RFC's, but I can't find it. > >> > >>draft-ietf-smime-msg-08.txt, section 3.3 > > > >Thanks. I knew I had read it, but couldn't find it. > > > >Now that I see the exact text once again, and given the apparent > >request by some to NOT keep a copy, I can live with SHOULD. > > > >> > >>Also, it should be noted that switching from MUST RC4 to MUST tripleDES > >>was the very first thing the ietf-smime group did, back 2 years ago. > >>There was a lot of discussion back then, all of it available on the IMC > >>mail archive. Not intended as a brush-off: there was a lot of relevant > >>debate. > >> > >I can certainly understand preferring triple-DES vs. RC4, but I'm still not > >thrilled about having a firm specification that it is illegal for me to > >comply with > >if I hope to export the product. I can fully understand that perhaps you > >might not share my concern on this point--neither do the Canadians, the > >Australians, or others! :-) > > > >But what would your position be if the situation were reversed, or if, for > >example, you could not export such a product to the US, and you might > >face losing half of your market as a result? > > > >I confess I haven't looked up the precise definition of MUST. Is there > >perhaps some face saving wriggle-room that says something like > >"except where prohibited by law or regulations"? > > > >Not being compliant with the RFC doesn't bother me all that much-- > >there aren't any IETF police, and procurements that require > >compatibility just won't get it, except for US/Canada domestic and > >certain industry sectors outside the US. > > > >What concerns me more is the assumption that because the > >standard says MUST, there is a presumption that it WILL > >actually be so, and that interoperability decisions about > >what kind of algorithms can be used can assume this as a default. > >T'ain't so, unfortunately, unless all of the US vendors roll over and > >play dead in the European and Asian markets. And that isn't > >going to happen. > > > >Regards, > > > >Bob > > > > > > > ------ > Software Agencies Australia Pty Ltd > 1 Huntingdale Road > Burwood, > Victoria 3125 > Australia > ACN 078 025 813 > Tel: +61-3-9808-0522 > Fax: +61-3-9888-6019 > Mobile: +61-41-222-3940 > Email: Andrew.Ferguson@software-aus.com.au > URL: www.software-aus.com.au > Your Business Partner in Electronic and Internet Commerce > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16716 for ietf-smime-bks; Wed, 19 May 1999 02:47:30 -0700 (PDT) Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16711 for <ietf-smime@imc.org>; Wed, 19 May 1999 02:47:28 -0700 (PDT) Received: from intouch1 (acc10-ppp23.mel.enternet.com.au [210.8.9.151]) by entoo.connect.com.au with SMTP id TAA16000 (8.8.8/IDA-1.7 for <ietf-smime@imc.org>); Wed, 19 May 1999 19:47:31 +1000 (EST) Message-Id: <4.1.19990519194705.009a9400@mail.enternet.com.au> X-Sender: aferguso@mail.enternet.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 19 May 1999 19:47:21 +1000 To: "ietf-smime@imc.org"<ietf-smime@imc.org> From: Andrew Ferguson <aferguso@enternet.com.au> Subject: RE: Issues with S/MIME Message Specification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Andrew, Robert, All, As a watcher, but not up to now an active participant in this debate on the matter of Issues with the S/MIME Message specification, I believe it should say SHOULD (definitly not MUST) and perhaps to be precise refer to the newly ratified Wassenaar agreement, eg : "except where prohibited under the Wassenaar Agreement" which will cover export and import into and from various countries. This will in effect provide a neat get out clause covering both issues. The reality as Bob points out below we Aussies are not necessarily worried about the US Export laws, but of course Australia now exports our own crypto developed products so we would also affected by the statement MUST. Anyway thats my contribution. At 10:34 19/05/99 , Robert R. Jueneman wrote: >>>With respect to the issue of bcc'ing the originator on an encrypted >>>message, although I suppose it is possible that the originator doesn't >>>have a public encryption key, this seems mildly unlikely, so I am more >>>inclined to agree with William Whyte's comment. >> >>I'm not sure that the My Esteemed Colleague's comment was anything >>more than a point of information. There will be situations when an >>application should include an originator key, but there are also counter >>examples. Locking a MUST into the standard is unnecessary, particularly >>since there's no compelling interoperability or security issue. >> >>>I wish I could find where I read that statement -- I thought it was in = >>>one of the RFC's, but I can't find it. >> >>draft-ietf-smime-msg-08.txt, section 3.3 > >Thanks. I knew I had read it, but couldn't find it. > >Now that I see the exact text once again, and given the apparent >request by some to NOT keep a copy, I can live with SHOULD. > >> >>Also, it should be noted that switching from MUST RC4 to MUST tripleDES >>was the very first thing the ietf-smime group did, back 2 years ago. >>There was a lot of discussion back then, all of it available on the IMC >>mail archive. Not intended as a brush-off: there was a lot of relevant >>debate. >> >I can certainly understand preferring triple-DES vs. RC4, but I'm still not >thrilled about having a firm specification that it is illegal for me to >comply with >if I hope to export the product. I can fully understand that perhaps you >might not share my concern on this point--neither do the Canadians, the >Australians, or others! :-) > >But what would your position be if the situation were reversed, or if, for >example, you could not export such a product to the US, and you might >face losing half of your market as a result? > >I confess I haven't looked up the precise definition of MUST. Is there >perhaps some face saving wriggle-room that says something like >"except where prohibited by law or regulations"? > >Not being compliant with the RFC doesn't bother me all that much-- >there aren't any IETF police, and procurements that require >compatibility just won't get it, except for US/Canada domestic and >certain industry sectors outside the US. > >What concerns me more is the assumption that because the >standard says MUST, there is a presumption that it WILL >actually be so, and that interoperability decisions about >what kind of algorithms can be used can assume this as a default. >T'ain't so, unfortunately, unless all of the US vendors roll over and >play dead in the European and Asian markets. And that isn't >going to happen. > >Regards, > >Bob > > ------ Software Agencies Australia Pty Ltd 1 Huntingdale Road Burwood, Victoria 3125 Australia ACN 078 025 813 Tel: +61-3-9808-0522 Fax: +61-3-9888-6019 Mobile: +61-41-222-3940 Email: Andrew.Ferguson@software-aus.com.au URL: www.software-aus.com.au Your Business Partner in Electronic and Internet Commerce Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16685 for ietf-smime-bks; Wed, 19 May 1999 02:45:37 -0700 (PDT) Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16680 for <ietf-smime@imc.org>; Wed, 19 May 1999 02:45:35 -0700 (PDT) Received: from intouch1 (acc10-ppp23.mel.enternet.com.au [210.8.9.151]) by entoo.connect.com.au with SMTP id TAA15381 (8.8.8/IDA-1.7); Wed, 19 May 1999 19:45:27 +1000 (EST) Message-Id: <4.1.19990519192734.0099b9c0@mail.enternet.com.au> X-Sender: aferguso@mail.enternet.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 19 May 1999 19:45:17 +1000 To: <bjueneman@novell.com>, "Andrew Farrell" <afarrell@baltimore.ie>, <ietf-smime@imc.org> From: Andrew Ferguson <aferguso@enternet.com.au> Subject: RE: Issues with S/MIME Message Specification Cc: "Robert R. Jueneman" <bjueneman@novell.com> In-Reply-To: <00d201bea18f$4a986850$4dd44189@provo.novell.com> References: <199905190005.BAA16423@ocelot.baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Andrew, Robert, All, As a watcher, but not up to now an active participant in this debate on the matter of Issues with the S/MIME Message specification, I believe it should say SHOULD (definitly not MUST) and perhaps to be precise refer to the newly ratified Wassenaar agreement, eg : "except where prohibited under the Wassenaar Agreement" which will cover export and import into and from various countries. This will in effect provide a neat get out clause covering both issues. The reality as Bob points out below we Aussies are not necessarily worried about the US Export laws, but of course Australia now exports our own crypto developed products so we would also affected by the statement MUST. Anyway thats my contribution. At 10:34 19/05/99 , Robert R. Jueneman wrote: >>>With respect to the issue of bcc'ing the originator on an encrypted >>>message, although I suppose it is possible that the originator doesn't >>>have a public encryption key, this seems mildly unlikely, so I am more >>>inclined to agree with William Whyte's comment. >> >>I'm not sure that the My Esteemed Colleague's comment was anything >>more than a point of information. There will be situations when an >>application should include an originator key, but there are also counter >>examples. Locking a MUST into the standard is unnecessary, particularly >>since there's no compelling interoperability or security issue. >> >>>I wish I could find where I read that statement -- I thought it was in = >>>one of the RFC's, but I can't find it. >> >>draft-ietf-smime-msg-08.txt, section 3.3 > >Thanks. I knew I had read it, but couldn't find it. > >Now that I see the exact text once again, and given the apparent >request by some to NOT keep a copy, I can live with SHOULD. > >> >>Also, it should be noted that switching from MUST RC4 to MUST tripleDES >>was the very first thing the ietf-smime group did, back 2 years ago. >>There was a lot of discussion back then, all of it available on the IMC >>mail archive. Not intended as a brush-off: there was a lot of relevant >>debate. >> >I can certainly understand preferring triple-DES vs. RC4, but I'm still not >thrilled about having a firm specification that it is illegal for me to >comply with >if I hope to export the product. I can fully understand that perhaps you >might not share my concern on this point--neither do the Canadians, the >Australians, or others! :-) > >But what would your position be if the situation were reversed, or if, for >example, you could not export such a product to the US, and you might >face losing half of your market as a result? > >I confess I haven't looked up the precise definition of MUST. Is there >perhaps some face saving wriggle-room that says something like >"except where prohibited by law or regulations"? > >Not being compliant with the RFC doesn't bother me all that much-- >there aren't any IETF police, and procurements that require >compatibility just won't get it, except for US/Canada domestic and >certain industry sectors outside the US. > >What concerns me more is the assumption that because the >standard says MUST, there is a presumption that it WILL >actually be so, and that interoperability decisions about >what kind of algorithms can be used can assume this as a default. >T'ain't so, unfortunately, unless all of the US vendors roll over and >play dead in the European and Asian markets. And that isn't >going to happen. > >Regards, > >Bob > > ------ Software Agencies Australia Pty Ltd 1 Huntingdale Road Burwood, Victoria 3125 Australia ACN 078 025 813 Tel: +61-3-9808-0522 Fax: +61-3-9888-6019 Mobile: +61-41-222-3940 Email: Andrew.Ferguson@software-aus.com.au URL: www.software-aus.com.au Your Business Partner in Electronic and Internet Commerce Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01143 for ietf-smime-bks; Tue, 18 May 1999 17:34:38 -0700 (PDT) Received: from orm-mail20.orem.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA01139 for <ietf-smime@imc.org>; Tue, 18 May 1999 17:34:37 -0700 (PDT) Received: from bobjuenemannt (stevecarroll.dnsdhcp.provo.novell.com [137.65.212.77]) by orm-mail20.orem.novell.com; Tue, 18 May 1999 18:34:00 -0600 Reply-To: <bjueneman@novell.com> From: "Robert R. Jueneman" <bjueneman@novell.com> To: "Andrew Farrell" <afarrell@baltimore.ie>, <ietf-smime@imc.org> Cc: "Robert R. Jueneman" <bjueneman@novell.com> Subject: RE: Issues with S/MIME Message Specification Date: Tue, 18 May 1999 18:34:01 -0600 Message-ID: <00d201bea18f$4a986850$4dd44189@provo.novell.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D3_01BEA15C.FFFDF850" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199905190005.BAA16423@ocelot.baltimore.ie> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_00D3_01BEA15C.FFFDF850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>With respect to the issue of bcc'ing the originator on an encrypted >>message, although I suppose it is possible that the originator doesn't >>have a public encryption key, this seems mildly unlikely, so I am more >>inclined to agree with William Whyte's comment. > >I'm not sure that the My Esteemed Colleague's comment was anything >more than a point of information. There will be situations when an >application should include an originator key, but there are also = counter >examples. Locking a MUST into the standard is unnecessary, particularly >since there's no compelling interoperability or security issue. > >>I wish I could find where I read that statement -- I thought it was in = =3D >>one of the RFC's, but I can't find it. > >draft-ietf-smime-msg-08.txt, section 3.3 Thanks. I knew I had read it, but couldn't find it. Now that I see the exact text once again, and given the apparent=20 request by some to NOT keep a copy, I can live with SHOULD. > >Also, it should be noted that switching from MUST RC4 to MUST tripleDES >was the very first thing the ietf-smime group did, back 2 years ago. >There was a lot of discussion back then, all of it available on the IMC >mail archive. Not intended as a brush-off: there was a lot of relevant >debate. > I can certainly understand preferring triple-DES vs. RC4, but I'm still = not=20 thrilled about having a firm specification that it is illegal for me to = comply with=20 if I hope to export the product. I can fully understand that perhaps = you=20 might not share my concern on this point--neither do the Canadians, the Australians, or others! :-) But what would your position be if the situation were reversed, or if, = for=20 example, you could not export such a product to the US, and you might=20 face losing half of your market as a result? I confess I haven't looked up the precise definition of MUST. Is there=20 perhaps some face saving wriggle-room that says something like "except where prohibited by law or regulations"? Not being compliant with the RFC doesn't bother me all that much-- there aren't any IETF police, and procurements that require=20 compatibility just won't get it, except for US/Canada domestic and=20 certain industry sectors outside the US. =20 What concerns me more is the assumption that because the=20 standard says MUST, there is a presumption that it WILL actually be so, and that interoperability decisions about=20 what kind of algorithms can be used can assume this as a default. T'ain't so, unfortunately, unless all of the US vendors roll over and=20 play dead in the European and Asian markets. And that isn't=20 going to happen. Regards, Bob ------=_NextPart_000_00D3_01BEA15C.FFFDF850 Content-Type: text/x-vcard; name="Robert R. Jueneman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Robert R. Jueneman.vcf" BEGIN:VCARD VERSION:2.1 N:Jueneman;Robert;R. FN:Robert R. Jueneman NICKNAME:Bob ORG:Novell, Inc.;Network Security Group TITLE:Security Architect NOTE;ENCODING=3DQUOTED-PRINTABLE:DISCLAIMER:=3D0D=3D0AIf this message or = document is digitally signed, and/or if =3D certificates are=3D0D=3D0Aattached, the intended purpose is to = =3D0D=3D0A (1) En=3D sure that e-mail came from the apparent sender=3D0D=3D0A (2) Protect = e-mail =3D from undetected tampering=3D0D=3D0A (3) Ensure that the content of = e-mail se=3D nt to me and encrypted in =3D0D=3D0A my dual-use key cannot be = viewed b=3D y others.=3D0D=3D0A=3D0D=3D0AIt is explicitly NOT the intent of any such = signed mess=3D age =3D0D=3D0Aor document to represent ANY type or form of legally = binding =3D0D=3D =3D0Acontract or other representation, and any such interpretation = =3D0D=3D0AWILL =3D BE REPUDIATED, notwithstanding any wording or =3D0D=3D0Aimplications to = the oppo=3D site effect in the text of the message =3D0D=3D0Aitself; due in part, = but not ex=3D clusively, because the security =3D0D=3D0Aof my workstation(s) and = associated cr=3D yptographic implementations=3D0D=3D0Aare not considered adequately = strong for su=3D ch purposes at present. TEL;WORK;VOICE:801/861-7387 TEL;CELL;VOICE:801/361-1410 TEL;WORK;FAX:801/861-2522 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;See DISCLAIMER under = "Other/Comment";122 E. 1700 South=3D0D=3D0A;Provo;Utah;846=3D 06;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:See DISCLAIMER under = "Other/Comment"=3D0D=3D0A122 E. 1700 South=3D0D=3D0A=3D0D=3D0AProvo=3D , Utah 84606=3D0D=3D0AUSA KEY;X509;ENCODING=3DBASE64: = MIIEczCCA9ygAwIBAgIQXqZDMWeC/paX54aALVA+3jANBgkqhkiG9w0BAQQFADCBzDEXMBUG = A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx = RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS = ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp = ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA1MTEwMDAwMDBa = Fw0wMDA1MTAyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT = FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw = b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl = cnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWlj = cm9zb2Z0IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPUm9iZXJ0IEp1ZW5lbWFuMSMwIQYJKoZI = hvcNAQkBFhRianVlbmVtYW5Abm92ZWxsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC = gYEA1bwdA1OgozL5U3MvQgSrdKhaZJjZCWy63SwzB7d/DMlH0OCUNAClR/Xe0ll1Tjxk3NEL = XpCRmzycUzaALIUAC/hCF8CRjKaFWqOsGK41Ozsrc7fRbSiTo2/q/9qiQchTq0DMsu4Ey5rK = 43uxLnwUN9xfAG9ps3948hqZHjRpA3kCAwEAAaOCAQYwggECMAkGA1UdEwQCMAAwgawGA1Ud = IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl = cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W = ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl = cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js = LnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBAGFtGYIj0JIcPa9g = k7JD0mxDw0oOZMApRjio3AZd+xBwT5a2v+++GWV8exxD8ljgYzR29HatgSr8jqcyTlSeWO7n = buptBixWgDgWpF1yXW0ZBHAFKxI8xLupOZufK6NzU8Dl0SNBG71VU2OkOINzecBxYV5vtKmN WarNq/mikm+L EMAIL;PREF;INTERNET:bjueneman@novell.com REV:19990514T154441Z END:VCARD ------=_NextPart_000_00D3_01BEA15C.FFFDF850-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA29078 for ietf-smime-bks; Tue, 18 May 1999 17:06:27 -0700 (PDT) Received: from puma.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29074 for <ietf-smime@imc.org>; Tue, 18 May 1999 17:06:25 -0700 (PDT) Received: by puma.baltimore.ie; id BAA23643; Wed, 19 May 1999 01:39:41 +0100 (GMT/IST) Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma023638; Wed, 19 May 99 01:39:00 +0100 Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.5) with ESMTP id BAA16423; Wed, 19 May 1999 01:05:47 +0100 Message-Id: <199905190005.BAA16423@ocelot.baltimore.ie> To: ietf-smime@imc.org Cc: bjueneman@novell.com Subject: Re: Issues with S/MIME Message Specification In-Reply-To: Your message of "Tue, 18 May 1999 16:26:42 MDT." <00ba01bea17d$812f7eb0$4dd44189@provo.novell.com> Date: Wed, 19 May 1999 01:05:47 +0100 From: Andrew Farrell <afarrell@baltimore.ie> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Robert Jeuneman writes: >Eric, >Thanks for your comments. I hadn't considered the possible difference >in scope between the S/MIME Message Specification and the CMS, but I can >see that CMS might have broader applicability, and hence, differing >requirements. This is also the reason why there are, on close examination, no MUSTs or SHOULDs in CMS. >With respect to the issue of bcc'ing the originator on an encrypted >message, although I suppose it is possible that the originator doesn't >have a public encryption key, this seems mildly unlikely, so I am more >inclined to agree with William Whyte's comment. I'm not sure that the My Esteemed Colleague's comment was anything more than a point of information. There will be situations when an application should include an originator key, but there are also counter examples. Locking a MUST into the standard is unnecessary, particularly since there's no compelling interoperability or security issue. >I wish I could find where I read that statement -- I thought it was in = >one of the RFC's, but I can't find it. draft-ietf-smime-msg-08.txt, section 3.3 Also, it should be noted that switching from MUST RC4 to MUST tripleDES was the very first thing the ietf-smime group did, back 2 years ago. There was a lot of discussion back then, all of it available on the IMC mail archive. Not intended as a brush-off: there was a lot of relevant debate. >Regards, >Bob Andrew. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA24157 for ietf-smime-bks; Tue, 18 May 1999 15:27:11 -0700 (PDT) Received: from orm-mail20.orem.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA24153 for <ietf-smime@imc.org>; Tue, 18 May 1999 15:27:10 -0700 (PDT) Received: from bobjuenemannt (stevecarroll.dnsdhcp.provo.novell.com [137.65.212.77]) by orm-mail20.orem.novell.com; Tue, 18 May 1999 16:26:41 -0600 Reply-To: <bjueneman@novell.com> From: "Robert R. Jueneman" <bjueneman@novell.com> To: <ekr@rtfm.com> Cc: <ietf-smime@imc.org> Subject: RE: Issues with S/MIME Message Specification Date: Tue, 18 May 1999 16:26:42 -0600 Message-ID: <00ba01bea17d$812f7eb0$4dd44189@provo.novell.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BB_01BEA14B.36950EB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <kj3e0u16z7.fsf@romeo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_00BB_01BEA14B.36950EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric, Thanks for your comments. I hadn't considered the possible difference = in scope between the S/MIME Message Specification and the CMS, but I can = see that CMS might have broader applicability, and hence, differing = requirements. I was also unaware of the fact that an information RFC had been = published on RC2, and withdraw my comments on that accordingly. With respect to the issue of bcc'ing the originator on an encrypted = message, although I suppose it is possible that the originator doesn't = have a public encryption key, this seems mildly unlikely, so I am more = inclined to agree with William Whyte's comment. I wish I could find where I read that statement -- I thought it was in = one of the RFC's, but I can't find it. Regards, Bob --------------------------- Robert R. Jueneman Novell, Inc. >-----Original Message----- >From: ekr@rtfm.com [mailto:ekr@rtfm.com] >Sent: Tuesday, May 18, 1999 2:03 PM >To: bjueneman@novell.com >Cc: The IESG; RFC Editor; ietf-smime@imc.org >Subject: Re: Issues with S/MIME Message Specification > > >"Robert R. Jueneman" <bjueneman@novell.com> writes: >> Regarding the S/MIME Version 3 Message Specification, >> draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs >> regarding specific cryptographic algorithms should be removed from = this >> document, and contained only in the Cryptographic Message Syntax=20 >document. >> I can see no reason at all why such things should be specified=20 >twice -- it >> just makes conformance checking all that much more difficult. An = example >> of this kind of difficulty is para 2.2 of the S/MIME Message >> Specification, which says that sending and receiving agents=20 >SHOULD support >> rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, = says >> that CMS implementations "may" support RSA. Neither mentions RSA = with >> OAEP. >CMS and S/MIME MSG intentionally have different requirements. >In order to preserve backwards compatibility with S/MIMEv2, >implementations SHOULD implement RSA. CMS implementations that >do not need to be used in the S/MIME context may very well >have no need to use RSA. > >> The second part of 2.7 specifies that receiving agents SHOULD support >> RC2/40 "or a compatible algorithm at a key size of 40 bits..." This >> recommendation suffers from two major problems, in my view. First, it = is >> LESS secure than 56-bit DES, which is now acceptable world-wide (with >> perhaps one or two minor exceptions -- not quite clear) for data >> encryption. >The purpose of this is once again for compatability with S/MIME v2=20 >which required RC2.=20 > >> And second, it is a proprietary, trade-secret algorithm.=20 >This statement is incorrect. See RFC-2268: > >2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. > January 1998. (Format: TXT=3D19048 bytes) (Status: INFORMATIONAL) > >> Finally, somewhere in these documents there is a statement regarding = the >> advisability of including the content encryption key encrypted in the >> originator's public key, but despite rereading the documents multiple >> times I can't find that text again. As I recall, the text said that = this >> SHOULD be done. I would argue that this should be changed to MUST, = for I >> can't imagine a situation where the originator of an encrypted = message >> would not want to be able to read his own message, for example in an >> outgoing or Sent-Mail queue. He might need to be able to decrypted, = and >> even retract it in order to resend it with modifications. It=20 >would not be >> reasonable to rely on the originator to bcc herself to gain this >> capability -- it ought to be required by the spec. >I disagree. Firstly, it's entirely possible that the originator >does not have a public key suitable for data encryption -- he >might have a signature only key. Secondly, encrypted content keys >take up a not-insignificant amount of space in the message. Mandating >this serves no interoperability requirement and therefore=20 >it's inappropriate. > >-Ekr > >--=20 >[Eric Rescorla ekr@rtfm.com] > ------=_NextPart_000_00BB_01BEA14B.36950EB0 Content-Type: text/x-vcard; name="Robert R. Jueneman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Robert R. Jueneman.vcf" BEGIN:VCARD VERSION:2.1 N:Jueneman;Robert;R. FN:Robert R. Jueneman NICKNAME:Bob ORG:Novell, Inc.;Network Security Group TITLE:Security Architect NOTE;ENCODING=3DQUOTED-PRINTABLE:DISCLAIMER:=3D0D=3D0AIf this message or = document is digitally signed, and/or if =3D certificates are=3D0D=3D0Aattached, the intended purpose is to = =3D0D=3D0A (1) En=3D sure that e-mail came from the apparent sender=3D0D=3D0A (2) Protect = e-mail =3D from undetected tampering=3D0D=3D0A (3) Ensure that the content of = e-mail se=3D nt to me and encrypted in =3D0D=3D0A my dual-use key cannot be = viewed b=3D y others.=3D0D=3D0A=3D0D=3D0AIt is explicitly NOT the intent of any such = signed mess=3D age =3D0D=3D0Aor document to represent ANY type or form of legally = binding =3D0D=3D =3D0Acontract or other representation, and any such interpretation = =3D0D=3D0AWILL =3D BE REPUDIATED, notwithstanding any wording or =3D0D=3D0Aimplications to = the oppo=3D site effect in the text of the message =3D0D=3D0Aitself; due in part, = but not ex=3D clusively, because the security =3D0D=3D0Aof my workstation(s) and = associated cr=3D yptographic implementations=3D0D=3D0Aare not considered adequately = strong for su=3D ch purposes at present. TEL;WORK;VOICE:801/861-7387 TEL;CELL;VOICE:801/361-1410 TEL;WORK;FAX:801/861-2522 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;See DISCLAIMER under = "Other/Comment";122 E. 1700 South=3D0D=3D0A;Provo;Utah;846=3D 06;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:See DISCLAIMER under = "Other/Comment"=3D0D=3D0A122 E. 1700 South=3D0D=3D0A=3D0D=3D0AProvo=3D , Utah 84606=3D0D=3D0AUSA KEY;X509;ENCODING=3DBASE64: = MIIEczCCA9ygAwIBAgIQXqZDMWeC/paX54aALVA+3jANBgkqhkiG9w0BAQQFADCBzDEXMBUG = A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx = RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS = ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp = ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA1MTEwMDAwMDBa = Fw0wMDA1MTAyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT = FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw = b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl = cnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWlj = cm9zb2Z0IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPUm9iZXJ0IEp1ZW5lbWFuMSMwIQYJKoZI = hvcNAQkBFhRianVlbmVtYW5Abm92ZWxsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC = gYEA1bwdA1OgozL5U3MvQgSrdKhaZJjZCWy63SwzB7d/DMlH0OCUNAClR/Xe0ll1Tjxk3NEL = XpCRmzycUzaALIUAC/hCF8CRjKaFWqOsGK41Ozsrc7fRbSiTo2/q/9qiQchTq0DMsu4Ey5rK = 43uxLnwUN9xfAG9ps3948hqZHjRpA3kCAwEAAaOCAQYwggECMAkGA1UdEwQCMAAwgawGA1Ud = IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl = cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W = ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl = cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js = LnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBAGFtGYIj0JIcPa9g = k7JD0mxDw0oOZMApRjio3AZd+xBwT5a2v+++GWV8exxD8ljgYzR29HatgSr8jqcyTlSeWO7n = buptBixWgDgWpF1yXW0ZBHAFKxI8xLupOZufK6NzU8Dl0SNBG71VU2OkOINzecBxYV5vtKmN WarNq/mikm+L EMAIL;PREF;INTERNET:bjueneman@novell.com REV:19990514T154441Z END:VCARD ------=_NextPart_000_00BB_01BEA14B.36950EB0-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA23374 for ietf-smime-bks; Tue, 18 May 1999 15:04:12 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA23370 for <ietf-smime@imc.org>; Tue, 18 May 1999 15:04:11 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 May 1999 16:03:26 -0600 Message-Id: <s7418f4e.053@prv-mail20.provo.novell.com> X-Mailer: Novell GroupWise 5.5 Date: Tue, 18 May 1999 16:03:21 -0600 From: "Bob Jueneman" <BJUENEMAN@novell.com> To: <jimsch@EXCHANGE.MICROSOFT.com> Cc: <ietf-smime@imc.org> Subject: RE: Issues with S/MIME Message Specification 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 mail.proper.com id PAA23371 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim, I still can't find the comment, so maybe I'm remembering something from an e-mail exchange or something -- is the statement included somewhere, or not? I can't tell from your message which functionality was requested -- that the self-encrypted message be included, or not. Or were you referring to a request to Microsoft, rather than to the IETF? In any case, although I value the human rights worker's cause, and also the whistle blower's, etc., there is another set of values that also needs to be addressed at the same time, and that is the need for either the business or the user to be able to recover encrypted messages, of various but legitimate purposes. One set of values doesn't necessarily trump the other -- they need to be debated on their merits. (Again, apologies if this issue was thrashed to death without my having seen it go by.) Bob >>> "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> 05/18/99 03:41PM >>> Finally, somewhere in these documents there is a statement regarding the advisability of including the content encryption key encrypted in the originator's public key, but despite rereading the documents multiple times I can't find that text again. As I recall, the text said that this SHOULD be done. I would argue that this should be changed to MUST, for I can't imagine a situation where the originator of an encrypted message would not want to be able to read his own message, for example in an outgoing or Sent-Mail queue. He might need to be able to decrypted, and even retract it in order to resend it with modifications. It would not be reasonable to rely on the originator to bcc herself to gain this capability -- it ought to be required by the spec. [Jim Schaad] This was a requested functionality by a group of people and is there for a reason. One situation in which this would be the case is human rights workers sending encrypted mail to the home office. They do not want the local police to be able to read the mail by stealing the machine and key or by force. jim schaad Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22532 for ietf-smime-bks; Tue, 18 May 1999 14:42:31 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22528 for <ietf-smime@imc.org>; Tue, 18 May 1999 14:42:30 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <K5PL53PC>; Tue, 18 May 1999 14:42:12 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5F7D@DINO> From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> To: "'bjueneman@novell.com'" <bjueneman@novell.com> Cc: ietf-smime@imc.org Subject: RE: Issues with S/MIME Message Specification Date: Tue, 18 May 1999 14:41:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Finally, somewhere in these documents there is a statement regarding the advisability of including the content encryption key encrypted in the originator's public key, but despite rereading the documents multiple times I can't find that text again. As I recall, the text said that this SHOULD be done. I would argue that this should be changed to MUST, for I can't imagine a situation where the originator of an encrypted message would not want to be able to read his own message, for example in an outgoing or Sent-Mail queue. He might need to be able to decrypted, and even retract it in order to resend it with modifications. It would not be reasonable to rely on the originator to bcc herself to gain this capability -- it ought to be required by the spec. [Jim Schaad] This was a requested functionality by a group of people and is there for a reason. One situation in which this would be the case is human rights workers sending encrypted mail to the home office. They do not want the local police to be able to read the mail by stealing the machine and key or by force. jim schaad Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21655 for ietf-smime-bks; Tue, 18 May 1999 13:55:53 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21651 for <ietf-smime@imc.org>; Tue, 18 May 1999 13:55:50 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id IAA05562; Wed, 19 May 1999 08:55:10 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92706091022781>; Wed, 19 May 1999 08:55:10 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: bjueneman@novell.com, ietf-smime@imc.org Subject: Re: Issues with S/MIME Message Specification Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Wed, 19 May 1999 08:55:10 (NZST) Message-ID: <92706091022781@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> [SHOULD -> MUST for encrypt-to-self] It's probably unnecessary to mention that there should have been a smiley after the X.400 comment in my previous message... another reason why saying anything on the use of encrypt-to-self is a bad thing is that it assumes that S/MIME mail will only ever be sent by humans. There are all sorts of protocols and messaging systems being built around S/MIME, for many of these encrypt-to-self is completely illogical or even dangerous (consider its use in medical EDI (HL7) messaging systems where the message indicates that the sender has been diagnosed with some terminal illness, that's something you definitely don't want the sender to stumble across unless they've been prepared for it). This is really a matter for users to decide, and not something which the standard should comment on. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20308 for ietf-smime-bks; Tue, 18 May 1999 13:13:57 -0700 (PDT) Received: from fax.imc.org (root@[207.94.139.160]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20304 for <ietf-smime@imc.org>; Tue, 18 May 1999 13:13:56 -0700 (PDT) Received: from aum (user@ip161.imc.org [207.94.139.161]) by fax.imc.org (8.9.3/8.9.0) with ESMTP id NAA01278; Tue, 18 May 1999 13:12:44 -0700 (PDT) Message-Id: <4.2.0.44.19990518130602.01edb6f0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.44 (Beta) Date: Tue, 18 May 1999 13:13:38 -0700 To: <bjueneman@novell.com> From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Issues with S/MIME Message Specification Cc: "RFC Editor" <rfc-editor@isi.edu>, <ietf-smime@imc.org> In-Reply-To: <006701bea15d$124b2e60$4dd44189@provo.novell.com> References: <199905171126.HAA17249@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> At 12:34 PM 5/18/99 -0600, Robert R. Jueneman wrote: >I sincerely regret not having had sufficient time to review the S/MIME v3 >specs in detail during last call and prior to their moving to Proposed >Standard, but I believe that there are several changes that absolutely >must be made before they can progress to final Standard. The issues you bring up here were not changed in the last call drafts. The location of the requirements for algorithms has been the same for over a year. I believe that it is inappropriate for you to object to the RFC Editor at this very late date. The step after they become Proposed Standards is to possibly become Draft Standards, not "final Standard". There will be plenty of time to discuss your issues in the Working Group in the interim. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20008 for ietf-smime-bks; Tue, 18 May 1999 13:03:26 -0700 (PDT) Received: from speedy.rtfm.com ([208.217.207.85]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20004 for <ietf-smime@imc.org>; Tue, 18 May 1999 13:03:23 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [208.217.207.82]) by speedy.rtfm.com (8.9.1/8.6.4) with ESMTP id NAA14617; Tue, 18 May 1999 13:03:24 -0700 (PDT) Received: (ekr@localhost) by romeo.rtfm.com (8.9.2/8.6.4) id NAA05143; Tue, 18 May 1999 13:02:52 -0700 (PDT) To: <bjueneman@novell.com> Cc: "The IESG" <iesg-secretary@ietf.org>, "RFC Editor" <rfc-editor@isi.edu>, <ietf-smime@imc.org> Subject: Re: Issues with S/MIME Message Specification References: <006701bea15d$124b2e60$4dd44189@provo.novell.com> From: EKR <ekr@rtfm.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 18 May 1999 13:02:52 -0700 In-Reply-To: "Robert R. Jueneman"'s message of "Tue, 18 May 1999 12:34:32 -0600" Message-ID: <kj3e0u16z7.fsf@romeo.rtfm.com> Lines: 55 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> "Robert R. Jueneman" <bjueneman@novell.com> writes: > Regarding the S/MIME Version 3 Message Specification, > draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs > regarding specific cryptographic algorithms should be removed from this > document, and contained only in the Cryptographic Message Syntax document. > I can see no reason at all why such things should be specified twice -- it > just makes conformance checking all that much more difficult. An example > of this kind of difficulty is para 2.2 of the S/MIME Message > Specification, which says that sending and receiving agents SHOULD support > rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says > that CMS implementations "may" support RSA. Neither mentions RSA with > OAEP. CMS and S/MIME MSG intentionally have different requirements. In order to preserve backwards compatibility with S/MIMEv2, implementations SHOULD implement RSA. CMS implementations that do not need to be used in the S/MIME context may very well have no need to use RSA. > The second part of 2.7 specifies that receiving agents SHOULD support > RC2/40 "or a compatible algorithm at a key size of 40 bits..." This > recommendation suffers from two major problems, in my view. First, it is > LESS secure than 56-bit DES, which is now acceptable world-wide (with > perhaps one or two minor exceptions -- not quite clear) for data > encryption. The purpose of this is once again for compatability with S/MIME v2 which required RC2. > And second, it is a proprietary, trade-secret algorithm. This statement is incorrect. See RFC-2268: 2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. January 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL) > Finally, somewhere in these documents there is a statement regarding the > advisability of including the content encryption key encrypted in the > originator's public key, but despite rereading the documents multiple > times I can't find that text again. As I recall, the text said that this > SHOULD be done. I would argue that this should be changed to MUST, for I > can't imagine a situation where the originator of an encrypted message > would not want to be able to read his own message, for example in an > outgoing or Sent-Mail queue. He might need to be able to decrypted, and > even retract it in order to resend it with modifications. It would not be > reasonable to rely on the originator to bcc herself to gain this > capability -- it ought to be required by the spec. I disagree. Firstly, it's entirely possible that the originator does not have a public key suitable for data encryption -- he might have a signature only key. Secondly, encrypted content keys take up a not-insignificant amount of space in the message. Mandating this serves no interoperability requirement and therefore it's inappropriate. -Ekr -- [Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18918 for ietf-smime-bks; Tue, 18 May 1999 12:35:29 -0700 (PDT) Received: from puma.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18914 for <ietf-smime@imc.org>; Tue, 18 May 1999 12:35:27 -0700 (PDT) Received: by puma.baltimore.ie; id VAA20768; Tue, 18 May 1999 21:08:38 +0100 (GMT/IST) Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma020753; Tue, 18 May 99 21:07:39 +0100 Received: from knuckle (knuckle.baltimore.ie [10.49.0.103]) by ocelot.baltimore.ie (8.8.7/8.8.5) with SMTP id UAA07751; Tue, 18 May 1999 20:34:29 +0100 Received: by localhost with Microsoft MAPI; Tue, 18 May 1999 20:33:58 +0100 Message-ID: <01BEA16D.C1807100.wwhyte@baltimore.ie> From: William Whyte <wwhyte@baltimore.ie> To: "'pgut001@cs.aucKland.ac.nz'" <pgut001@cs.aucKland.ac.nz>, "bjueneman@novell.com" <bjueneman@novell.com>, "ietf-smime@imc.org" <ietf-smime@imc.org> Subject: RE: Issues with S/MIME Message Specification Date: Tue, 18 May 1999 20:33:57 +0100 Organization: Baltimore Technologies 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: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> > >Finally, somewhere in these documents there is a statement regarding the > >advisability of including the content encryption key encrypted in the > >originator's public key, but despite rereading the documents multiple > >times I can't find that text again. As I recall, the text said that this > >SHOULD be done.... > > Given that anyone who wants to re-read their own messages will keep a copy > stored locally, why on earth would they go through the complex encrypt-> > decrypt process just to read what they've written? I think even the presence > of SHOULD is too restrictire for this, > ... > Anyone who > needs sent-mail revocation and whatnot desperately enough can go use X.400 > for their mail. Not quite right. If you're using (for example) Outlook, the message that's stored in your Sent Mail box is the message that was actually sent. You need to have encrypted it to yourself to be able to read it subsequently. William Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18126 for ietf-smime-bks; Tue, 18 May 1999 12:09:50 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18122 for <ietf-smime@imc.org>; Tue, 18 May 1999 12:09:48 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id HAA00587; Wed, 19 May 1999 07:08:52 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92705453217604>; Wed, 19 May 1999 07:08:52 (NZST) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: bjueneman@novell.com, iesg-secretary@ietf.org, ietf-smime@imc.org Subject: Re: Issues with S/MIME Message Specification Reply-To: pgut001@cs.aucKland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Wed, 19 May 1999 07:08:52 (NZST) Message-ID: <92705453217604@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> [Recipient list trimmed somewhat] "Robert R. Jueneman" <bjueneman@novell.com> writes: >Finally, somewhere in these documents there is a statement regarding the >advisability of including the content encryption key encrypted in the >originator's public key, but despite rereading the documents multiple >times I can't find that text again. As I recall, the text said that this >SHOULD be done. I would argue that this should be changed to MUST, for I >can't imagine a situation where the originator of an encrypted message >would not want to be able to read his own message, Given that anyone who wants to re-read their own messages will keep a copy stored locally, why on earth would they go through the complex encrypt-> decrypt process just to read what they've written? I think even the presence of SHOULD is too restrictire for this, it's purely a matter for the sender to decide and doesn't really have any place in MSG - for the majority of users all it'll do is double the number of keys available for attack. Anyone who needs sent-mail revocation and whatnot desperately enough can go use X.400 for their mail. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17355 for ietf-smime-bks; Tue, 18 May 1999 11:35:56 -0700 (PDT) Received: from orm-mail20.orem.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA17349 for <ietf-smime@imc.org>; Tue, 18 May 1999 11:35:24 -0700 (PDT) Received: from bobjuenemannt (stevecarroll.dnsdhcp.provo.novell.com [137.65.212.77]) by orm-mail20.orem.novell.com; Tue, 18 May 1999 12:34:31 -0600 Reply-To: <bjueneman@novell.com> From: "Robert R. Jueneman" <bjueneman@novell.com> To: "The IESG" <iesg-secretary@ietf.org> Cc: "RFC Editor" <rfc-editor@isi.edu>, <ietf-smime@imc.org>, "Robert R. Jueneman" <bjueneman@novell.com> Subject: Issues with S/MIME Message Specification Date: Tue, 18 May 1999 12:34:32 -0600 MIME-Version: 1.0 Message-ID: <006701bea15d$124b2e60$4dd44189@provo.novell.com> X-Priority: 3 (Normal) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01BEA118.F1833EF0" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199905171126.HAA17249@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0052_01BEA118.F1833EF0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004F_01BEA118.F156D7C0" ------=_NextPart_000_004F_01BEA118.F156D7C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I sincerely regret not having had sufficient time to review the S/MIME v3 specs in detail during last call and prior to their moving to Proposed Standard, but I believe that there are several changes that absolutely must be made before they can progress to final Standard. Regarding the S/MIME Version 3 Message Specification, draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs regarding specific cryptographic algorithms should be removed from this document, and contained only in the Cryptographic Message Syntax document. I can see no reason at all why such things should be specified twice -- it just makes conformance checking all that much more difficult. An example of this kind of difficulty is para 2.2 of the S/MIME Message Specification, which says that sending and receiving agents SHOULD support rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says that CMS implementations "may" support RSA. Neither mentions RSA with OAEP. This affects section 2.1, 2.2, and 2.3, and most emphatically section 2.7, "ContentEncryption AlgorithmIdentifier", and 2.7.1.3 "Rule 3, Unknown Capabilities, Unknown Version of S/MIME." Without getting into international politics, at the present time triple-DES is not exportable from the US, at the very least, and may very well not be importable into some other countries. Specifying that S/MIME agents MUST implement triple-DES therefore presents a vendor with Hobson's choice -- they can either chose not to be compliant with the RFC, or they can chose not to export their product. Unfortunately, that is no choice at all -- any sane US vendor will choose not to be compliant with the RFC, rather than lose perhaps 50% of their market. The only purpose such a red-flag-in-front-of-the-bull statement serves, therefore, is a political one, and one that will merely lower the credibility of the IETF and the IESG in the vendor and business community. At most the requirement should be SHOULD. The second part of 2.7 specifies that receiving agents SHOULD support RC2/40 "or a compatible algorithm at a key size of 40 bits..." This recommendation suffers from two major problems, in my view. First, it is LESS secure than 56-bit DES, which is now acceptable world-wide (with perhaps one or two minor exceptions -- not quite clear) for data encryption. And second, it is a proprietary, trade-secret algorithm. Not only is that contrary to the general direction of the IETF in not mandating proprietary algorithms, but the fact that it is a trade secret (not withstanding the fact that it has been reverse engineered) means that there has not been adequate attention paid to its security in the academic cryptanalytic community. RC2 of any size may well be worth considering for support, and might deserve RECOMMENDED status, but that should be up to the vendor. If RC2 is required for backwards compatibility with S/MIME v2, then a paragraph noting that fact would be appropriate, as was provided as the last paragraph under 2.3 ("Note that S/MIME v2 clients are only capable of decrypting content encryption keys using the rsaEncryption algorithm."). (I am taking this position with no lack of respect for Ron Rivest, whom I consider a very able cryptographer. But I would take that position if God Herself had invented but not published some particular algorithm.) With respect to 2.7.1.3, there are two problems. First, it mandates triple-DES, which very well may not be available at to the recipient, and secondly, it recommends as a fall back position the use of the trade-secret RC2/40. Both statements should be removed. The CMS specification should then develop a list of algorithms in rough order of strength, to be used for such negotiations as required. Finally, somewhere in these documents there is a statement regarding the advisability of including the content encryption key encrypted in the originator's public key, but despite rereading the documents multiple times I can't find that text again. As I recall, the text said that this SHOULD be done. I would argue that this should be changed to MUST, for I can't imagine a situation where the originator of an encrypted message would not want to be able to read his own message, for example in an outgoing or Sent-Mail queue. He might need to be able to decrypted, and even retract it in order to resend it with modifications. It would not be reasonable to rely on the originator to bcc herself to gain this capability -- it ought to be required by the spec. I will be addressing my concerns with the CMS specification in a subsequent message. Bob --------------------------- Robert R. Jueneman Novell, Inc. (See digital signature DISCLAIMER in attached vCard) >-----Original Message----- >From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On >Behalf Of The IESG >Sent: Monday, May 17, 1999 5:26 AM >To: IETF-Announce: ; >Cc: RFC Editor; Internet Architecture Board; ietf-smime@imc.org >Subject: Protocol Action: Cryptographic Message Syntax to Proposed >Standard > > > > >The IESG has approved publication of the following Internet-Drafts as >Proposed Standards: > > o Cryptographic Message Syntax <draft-ietf-smime-cms-13.txt> > o Diffie-Hellman Key Agreement Method <draft-ietf-smime-x942-07.txt> > o S/MIME Version 3 Certificate Handling <draft-ietf-smime-cert-08.txt> > o S/MIME Version 3 Message Specification <draft-ietf-smime-msg-08.txt> > o Enhanced Security Services for S/MIME <draft-ietf-smime-ess-12.txt> > >These documents are the product of the S/MIME Mail Security Working Group. >The IESG contact persons are Jeffrey Schiller and Marcus Leech. > > >Technical Summary > >These documents describe Version 3 of S/MIME (Secure/Multipurpose >Internet Mail Extensions). S/MIME provides for the secure >communication of MIME Objects, providing Authentication, Integrity and >Confidentiality protection. It can be used wherever MIME is used, as >it is fully conformant with the general MIME specifications. The >documents here provide for the basic message syntax and semantics as >well as the certificate and key management infrastructure >required. This work is coordinated and builds upon the work of the >IETF X.509 Public Key Infrastructure Working Group (PKIX). > >In addition to the basic security services mentioned above, several >optional services are described. These include signed receipt >handling, security labeling of objects, secure mailing lists and >signing certificates. > >Working Group Summary > >The working group came to consensus on the work described here. A lot >of people contributed thoughtful, useful and constructive comments >during the review periods which resulted in further improvements >reflected in these documents. > >Jeffrey I. Schiller reviewed the specification for IESG. > > ------=_NextPart_000_004F_01BEA118.F156D7C0 Content-Type: text/x-vcard; name="Robert R. Jueneman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Robert R. Jueneman.vcf" BEGIN:VCARD VERSION:2.1 N:Jueneman;Robert;R. FN:Robert R. Jueneman NICKNAME:Bob ORG:Novell, Inc.;Network Security Group TITLE:Security Architect NOTE;ENCODING=3DQUOTED-PRINTABLE:DISCLAIMER:=3D0D=3D0AIf this message or = document is digitally signed, and/or if =3D certificates are=3D0D=3D0Aattached, the intended purpose is to = =3D0D=3D0A (1) En=3D sure that e-mail came from the apparent sender=3D0D=3D0A (2) Protect = e-mail =3D from undetected tampering=3D0D=3D0A (3) Ensure that the content of = e-mail se=3D nt to me and encrypted in =3D0D=3D0A my dual-use key cannot be = viewed b=3D y others.=3D0D=3D0A=3D0D=3D0AIt is explicitly NOT the intent of any such = signed mess=3D age =3D0D=3D0Aor document to represent ANY type or form of legally = binding =3D0D=3D =3D0Acontract or other representation, and any such interpretation = =3D0D=3D0AWILL =3D BE REPUDIATED, notwithstanding any wording or =3D0D=3D0Aimplications to = the oppo=3D site effect in the text of the message =3D0D=3D0Aitself; due in part, = but not ex=3D clusively, because the security =3D0D=3D0Aof my workstation(s) and = associated cr=3D yptographic implementations=3D0D=3D0Aare not considered adequately = strong for su=3D ch purposes at present. TEL;WORK;VOICE:801/861-7387 TEL;CELL;VOICE:801/361-1410 TEL;WORK;FAX:801/861-2522 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;See DISCLAIMER under = "Other/Comment";122 E. 1700 South=3D0D=3D0A;Provo;Utah;846=3D 06;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:See DISCLAIMER under = "Other/Comment"=3D0D=3D0A122 E. 1700 South=3D0D=3D0A=3D0D=3D0AProvo=3D , Utah 84606=3D0D=3D0AUSA KEY;X509;ENCODING=3DBASE64: = MIIEczCCA9ygAwIBAgIQXqZDMWeC/paX54aALVA+3jANBgkqhkiG9w0BAQQFADCBzDEXMBUG = A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx = RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS = ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp = ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA1MTEwMDAwMDBa = Fw0wMDA1MTAyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT = FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw = b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl = cnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWlj = cm9zb2Z0IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPUm9iZXJ0IEp1ZW5lbWFuMSMwIQYJKoZI = hvcNAQkBFhRianVlbmVtYW5Abm92ZWxsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC = gYEA1bwdA1OgozL5U3MvQgSrdKhaZJjZCWy63SwzB7d/DMlH0OCUNAClR/Xe0ll1Tjxk3NEL = XpCRmzycUzaALIUAC/hCF8CRjKaFWqOsGK41Ozsrc7fRbSiTo2/q/9qiQchTq0DMsu4Ey5rK = 43uxLnwUN9xfAG9ps3948hqZHjRpA3kCAwEAAaOCAQYwggECMAkGA1UdEwQCMAAwgawGA1Ud = IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl = cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W = ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl = cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js = LnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBAGFtGYIj0JIcPa9g = k7JD0mxDw0oOZMApRjio3AZd+xBwT5a2v+++GWV8exxD8ljgYzR29HatgSr8jqcyTlSeWO7n = buptBixWgDgWpF1yXW0ZBHAFKxI8xLupOZufK6NzU8Dl0SNBG71VU2OkOINzecBxYV5vtKmN WarNq/mikm+L EMAIL;PREF;INTERNET:bjueneman@novell.com REV:19990514T154441Z END:VCARD ------=_NextPart_000_004F_01BEA118.F156D7C0-- ------=_NextPart_000_0052_01BEA118.F1833EF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHqTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS xVhqwY0DPOvDzQWikK5uMIIEczCCA9ygAwIBAgIQXqZDMWeC/paX54aALVA+3jANBgkqhkiG9w0B AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA1MTEwMDAwMDBa Fw0wMDA1MTAyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwg U2VydmljZTEYMBYGA1UEAxQPUm9iZXJ0IEp1ZW5lbWFuMSMwIQYJKoZIhvcNAQkBFhRianVlbmVt YW5Abm92ZWxsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1bwdA1OgozL5U3MvQgSr dKhaZJjZCWy63SwzB7d/DMlH0OCUNAClR/Xe0ll1Tjxk3NELXpCRmzycUzaALIUAC/hCF8CRjKaF WqOsGK41Ozsrc7fRbSiTo2/q/9qiQchTq0DMsu4Ey5rK43uxLnwUN9xfAG9ps3948hqZHjRpA3kC AwEAAaOCAQYwggECMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4w KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAV Fg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5j ZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAGFtGYIj0JIcPa9gk7JD0mxDw0oOZMApRjio3AZd+xBwT5a2v+++GWV8exxD8ljgYzR29Hat gSr8jqcyTlSeWO7nbuptBixWgDgWpF1yXW0ZBHAFKxI8xLupOZufK6NzU8Dl0SNBG71VU2OkOINz ecBxYV5vtKmNWarNq/mikm+LMYIDODCCAzQCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEF6mQzFngv6Wl+eGgC1QPt4wCQYFKw4DAhoFAKCCAawwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwNTE4MTYyNjUxWjAjBgkqhkiG9w0BCQQx FgQUZQLtFGOQaMjHXIdIyzXJQQ0e7uYwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUw gfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQ XqZDMWeC/paX54aALVA+3jANBgkqhkiG9w0BAQEFAASBgEdDBPD1ArWm8nip+2C2dv2PZsNrIBDn 7Lf+D1/K2/mfEOD7LOHLav/TChwyjgVGUTkmmFE0HYGFjUzBXIctVGuPy50X94xjemfThyPh3XB/ uBETxem5Omqs9J5ubPSi6CIuQXqa/2MZUWO8Cl9qj6dRk1nDamNQQhOl4HVvqwmHAAAAAAAA ------=_NextPart_000_0052_01BEA118.F1833EF0-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18610 for ietf-smime-bks; Mon, 17 May 1999 12:14:07 -0700 (PDT) Received: from mail.cybersource.com (mail.cybersource.com [207.82.53.181]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18606 for <ietf-smime@imc.org>; Mon, 17 May 1999 12:14:06 -0700 (PDT) Received: from warakurna (warakurna.cybersource.com [10.2.5.23]) by mail.cybersource.com (8.9.1/8.9.1) with SMTP id MAA17661; Mon, 17 May 1999 12:09:30 -0700 (PDT) Message-Id: <4.1.19990517120453.00946100@pop3.cybersource.com> X-Sender: jeaton@pop3.cybersource.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 17 May 1999 12:12:20 -0700 To: discuss@apps.ietf.org, ietf-smime@imc.org From: Jason Eaton <jeaton@cybersource.com> Subject: SCMP Mail Discussion List Cc: toma@cybersource.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Simple Commerce Messaging Protocol ( SCMP ) SCMP is a general purpose commerce messaging protocol based on S/MIME. There is a new mail list for discussion of the SCMP draft ( draft-arnold-scmp-02.txt ). Paul Hoffman at IMC has generously agreed to host the list. To subscribe, send a message to "ietf-scmp-request@imc.org" with the word "subscribe" in the body of the message. Thanks. Jason Eaton CyberSource Corporation Phone 408.260.6044 Security Engineering Manager jeaton@cybersource.com http://www.cybersource.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA15095 for ietf-smime-bks; Mon, 17 May 1999 04:27:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA15090 for <ietf-smime@imc.org>; Mon, 17 May 1999 04:27:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17249; Mon, 17 May 1999 07:26:04 -0400 (EDT) Message-Id: <199905171126.HAA17249@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: ietf-smime@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Protocol Action: Cryptographic Message Syntax to Proposed Standard Date: Mon, 17 May 1999 07:26:04 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o Cryptographic Message Syntax <draft-ietf-smime-cms-13.txt> o Diffie-Hellman Key Agreement Method <draft-ietf-smime-x942-07.txt> o S/MIME Version 3 Certificate Handling <draft-ietf-smime-cert-08.txt> o S/MIME Version 3 Message Specification <draft-ietf-smime-msg-08.txt> o Enhanced Security Services for S/MIME <draft-ietf-smime-ess-12.txt> These documents are the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary These documents describe Version 3 of S/MIME (Secure/Multipurpose Internet Mail Extensions). S/MIME provides for the secure communication of MIME Objects, providing Authentication, Integrity and Confidentiality protection. It can be used wherever MIME is used, as it is fully conformant with the general MIME specifications. The documents here provide for the basic message syntax and semantics as well as the certificate and key management infrastructure required. This work is coordinated and builds upon the work of the IETF X.509 Public Key Infrastructure Working Group (PKIX). In addition to the basic security services mentioned above, several optional services are described. These include signed receipt handling, security labeling of objects, secure mailing lists and signing certificates. Working Group Summary The working group came to consensus on the work described here. A lot of people contributed thoughtful, useful and constructive comments during the review periods which resulted in further improvements reflected in these documents. Jeffrey I. Schiller reviewed the specification for IESG. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15127 for ietf-smime-bks; Wed, 12 May 1999 10:21:59 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15123 for <ietf-smime@imc.org>; Wed, 12 May 1999 10:21:58 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2580.0) id <JYTLN654>; Wed, 12 May 1999 10:24:02 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5F4D@DINO> From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> To: "'jsp@jgvandyke.com'" <jsp@jgvandyke.com>, ietf-smime@imc.org Cc: jsp@ajsn101.jgvandyke.com Subject: RE: Receipt Request Attribute Date: Wed, 12 May 1999 10:24:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> All, I had forgotten about the text in section 1.3.4 -- I agree that would disallow the placment in a receipt request in a counter signature. I also agree that I don't have a reason for doing receipt requests in counter signatures, but I have also learned never to underestimate the things needed by somebody in the market that I have never heard of and will hopefully never hear from. Given that the question was being asked I made the assumption that Tom had some type of requirement that might require this type of behavior. jim -----Original Message----- From: jsp@jgvandyke.com [mailto:jsp@jgvandyke.com] Sent: Wednesday, May 12, 1999 8:56 AM To: Jim Schaad (Exchange); ietf-smime@imc.org Cc: jsp@ajsn101.jgvandyke.com Subject: Re: Receipt Request Attribute All, I respectfully disagree with Jim's reply to Tom's message. First, ESS Section 1.3.4, Placement of Attributes, states: "The only attributes that are allowed in a counterSignature attribute are counterSignature, messageDigest, signingTime, and signingCertificates." This means that receiptRequest attributes are not allowed to be carried in a counterSignature attribute. Second, IMHO, it does not make sense to request a signedReceipt for a counterSignature. A signedReceipt is intended to prove that a recipient received and was able to verify the signature of the message sent by the signer. What would a signedReceipt prove for a counterSignature since the thing that is signed is not a message, it is the originator's signature of the original message??? I do not believe that we should change ESS to allow receiptRequests to be included in counterSignature attributes. - John Pawling > > Tom, > > My opinion on this would be: > > 1. A CounterSignature can contain a receipt request. > 2. The receipt request on the original SignedData and the receipt receipt > on the CounterSignature can be different. The requirement is that all > receipt requests in a SignerInfo sequence be the same and a CounterSigner > has a different SignerInfo sequence > > jim > > > -----Original Message----- > From: Tom Kung [mailto:Tom.Kung@entrust.com] > Sent: Monday, May 10, 1999 11:48 AM > To: 'ietf-smime@imc.org' > Subject: Receipt Request Attribute > > > Gooday, > > I would appreciate clarification on the following with respect to the > Receipt Request attribute: > > 1. May a CounterSignature contain a receipt request? > > 2. If so, MUST all receipt requests in a SignedData be identical? The > spec specifies that all Receipt Requests be identical. Is it the intent > that CounterSignatures containing a receipt request MUST also be identical > with other receipt requests if it exists? I don't see why each > countersignature can not have a different receipt request. > > > thanx,tom. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14342 for ietf-smime-bks; Wed, 12 May 1999 08:50:19 -0700 (PDT) Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14338 for <ietf-smime@imc.org>; Wed, 12 May 1999 08:50:18 -0700 (PDT) Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id LAA06963; Wed, 12 May 1999 11:59:46 -0400 (EDT) Received: by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id LAA26409; Wed, 12 May 1999 11:56:30 -0400 From: jsp@jgvandyke.com (John Pawling) Message-Id: <199905121556.LAA26409@ajsn101.jgvandyke.com> Subject: Re: Receipt Request Attribute To: jimsch@EXCHANGE.MICROSOFT.com (Jim Schaad), ietf-smime@imc.org Date: Wed, 12 May 1999 11:56:29 -0400 (EDT) Cc: jsp@ajsn101.jgvandyke.com In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5F31@DINO> from "Jim Schaad" at May 10, 99 12:49:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> All, I respectfully disagree with Jim's reply to Tom's message. First, ESS Section 1.3.4, Placement of Attributes, states: "The only attributes that are allowed in a counterSignature attribute are counterSignature, messageDigest, signingTime, and signingCertificates." This means that receiptRequest attributes are not allowed to be carried in a counterSignature attribute. Second, IMHO, it does not make sense to request a signedReceipt for a counterSignature. A signedReceipt is intended to prove that a recipient received and was able to verify the signature of the message sent by the signer. What would a signedReceipt prove for a counterSignature since the thing that is signed is not a message, it is the originator's signature of the original message??? I do not believe that we should change ESS to allow receiptRequests to be included in counterSignature attributes. - John Pawling > > Tom, > > My opinion on this would be: > > 1. A CounterSignature can contain a receipt request. > 2. The receipt request on the original SignedData and the receipt receipt > on the CounterSignature can be different. The requirement is that all > receipt requests in a SignerInfo sequence be the same and a CounterSigner > has a different SignerInfo sequence > > jim > > > -----Original Message----- > From: Tom Kung [mailto:Tom.Kung@entrust.com] > Sent: Monday, May 10, 1999 11:48 AM > To: 'ietf-smime@imc.org' > Subject: Receipt Request Attribute > > > Gooday, > > I would appreciate clarification on the following with respect to the > Receipt Request attribute: > > 1. May a CounterSignature contain a receipt request? > > 2. If so, MUST all receipt requests in a SignedData be identical? The > spec specifies that all Receipt Requests be identical. Is it the intent > that CounterSignatures containing a receipt request MUST also be identical > with other receipt requests if it exists? I don't see why each > countersignature can not have a different receipt request. > > > thanx,tom. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA08511 for ietf-smime-bks; Tue, 11 May 1999 19:57:32 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA08497; Tue, 11 May 1999 19:57:28 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <JYW3AHYS>; Tue, 11 May 1999 19:59:46 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5F4A@DINO> From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> To: "Russ Housley (E-mail)" <housley@spyrus.com> Cc: "Ietf-Smime (E-mail)" <ietf-smime@imc.org>, "Paul Hoffman (E-mail)" <phoffman@imc.org> Subject: New SMime Capabilities item Date: Tue, 11 May 1999 19:59:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Please add the following to the SMimeCapabilities section of the OIDs document on IMC.ORG. sMIMECapabilitiesVersions ::= {sMIMECapabilities 3} SMIMECapabilitiesVersions ::= SEQUENCE OF INTEGER -- SMime Capabilities Versions holds the sequence of S/MIME V3 specifications -- understood by the client. Currently the only two items legal values are -- v2 (S/MIME version 2) and v3 (S/MIME version 3). If the item is missing from a -- capabilities list then V2 only should be assumed. The current justification for this is that S/MIME V2 clients will probably not understand the CMS encrypted data objects. Specifically receipient infos other than key transport and may not be able to decrypt the message at all if other key managment algorithms are used in the message. jim Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA04992 for ietf-smime-bks; Mon, 10 May 1999 12:47:36 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04988 for <ietf-smime@imc.org>; Mon, 10 May 1999 12:47:36 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <JYWN0LMW>; Mon, 10 May 1999 12:49:46 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5F31@DINO> From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> To: "'Tom Kung'" <Tom.Kung@entrust.com>, "'ietf-smime@imc.org'" <ietf-smime@imc.org> Subject: RE: Receipt Request Attribute Date: Mon, 10 May 1999 12:49:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Tom, My opinion on this would be: 1. A CounterSignature can contain a receipt request. 2. The receipt request on the original SignedData and the receipt receipt on the CounterSignature can be different. The requirement is that all receipt requests in a SignerInfo sequence be the same and a CounterSigner has a different SignerInfo sequence jim -----Original Message----- From: Tom Kung [mailto:Tom.Kung@entrust.com] Sent: Monday, May 10, 1999 11:48 AM To: 'ietf-smime@imc.org' Subject: Receipt Request Attribute Gooday, I would appreciate clarification on the following with respect to the Receipt Request attribute: 1. May a CounterSignature contain a receipt request? 2. If so, MUST all receipt requests in a SignedData be identical? The spec specifies that all Receipt Requests be identical. Is it the intent that CounterSignatures containing a receipt request MUST also be identical with other receipt requests if it exists? I don't see why each countersignature can not have a different receipt request. thanx,tom. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA04548 for ietf-smime-bks; Mon, 10 May 1999 11:59:15 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA04544 for <ietf-smime@imc.org>; Mon, 10 May 1999 11:59:13 -0700 (PDT) Received: id OAA12435; Mon, 10 May 1999 14:53:56 -0400 Received: by gateway id <J96LC6NW>; Mon, 10 May 1999 14:56:20 -0400 Message-ID: <ED026032A3FCD211AEDA00105A9C46960339B4@sothmxs05.entrust.com> From: Tom Kung <Tom.Kung@entrust.com> To: "'ietf-smime@imc.org'" <ietf-smime@imc.org> Subject: Receipt Request Attribute Date: Mon, 10 May 1999 14:47:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Gooday, I would appreciate clarification on the following with respect to the Receipt Request attribute: 1. May a CounterSignature contain a receipt request? 2. If so, MUST all receipt requests in a SignedData be identical? The spec specifies that all Receipt Requests be identical. Is it the intent that CounterSignatures containing a receipt request MUST also be identical with other receipt requests if it exists? I don't see why each countersignature can not have a different receipt request. thanx,tom. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05596 for ietf-smime-bks; Fri, 7 May 1999 16:41:07 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05591 for <ietf-smime@imc.org>; Fri, 7 May 1999 16:41:06 -0700 (PDT) Message-Id: <4.2.0.37.19990507164238.009f3d80@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Fri, 07 May 1999 16:42:42 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Mailing loop problem; probably solved Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Hi there. Some of you have gotten multiple copies of two messages sent to the list. I believe we found the culprit and have fixed the problem. If you get multiple copies of *this* message, it means that we didn't get it fixed on the first round, but I'll be watching carefully. PLEASE DO NOT RESPOND TO THE LIST ABOUT THIS; if you want to talk about it, please send me individual mail. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14125 for ietf-smime-bks; Fri, 7 May 1999 11:12:54 -0700 (PDT) Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14114 for <ietf-smime@imc.org>; Fri, 7 May 1999 11:12:48 -0700 (PDT) Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id OAA10519 for <ietf-smime@imc.org>; Fri, 7 May 1999 14:21:51 -0400 (EDT) Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id OAA15086; Fri, 7 May 1999 14:18:40 -0400 Date: Fri, 7 May 1999 14:18:40 -0400 Message-Id: <199905071818.OAA15086@ajsn101.jgvandyke.com> X-Sender: jsp@ajsn101 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> From: jsp@jgvandyke.com (John Pawling) Subject: RE: More Re: Comments on cmskea Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim, Thank you for your concurrence. If I do not hear any objections from anybody by 14 May, then I will submit a new CMSKEA I-D that includes the previously discussed recommendations. - John Pawling At 10:44 AM 5/7/99 -0700, Jim Schaad (Exchange) wrote: >John, > >After having worked my way through this, I think it is completely acceptable >and should be done. This addresses the major problem I had and make things >more in line with the D-H items. > >jim > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12646 for ietf-smime-bks; Fri, 7 May 1999 10:43:04 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12641 for <ietf-smime@imc.org>; Fri, 7 May 1999 10:43:02 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <JYWN9MKS>; Fri, 7 May 1999 10:44:56 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5F1D@DINO> From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> To: "'jsp@jgvandyke.com'" <jsp@jgvandyke.com>, "Ietf-Smime (E-mail)" <ietf-smime@imc.org> Subject: RE: More Re: Comments on cmskea Date: Fri, 7 May 1999 10:44:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> John, After having worked my way through this, I think it is completely acceptable and should be done. This addresses the major problem I had and make things more in line with the D-H items. jim -----Original Message----- From: jsp@jgvandyke.com [mailto:jsp@jgvandyke.com] Sent: Thursday, May 06, 1999 10:36 AM To: Ietf-Smime (E-mail) Subject: More Re: Comments on cmskea Jim and friends, Please substitute "id-kEAKeyEncryptionAlgorithm" for "id-KEA" in my earlier message. Also, change the definition to: "id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}. - John Pawling Previous message: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Jim, Thank you very much for your feedback regarding the "CMS KEA and SKIPJACK Conventions" (CMSKEA) I-D. I apologize for not answering your message sooner. I believe that you make an excellent point that the id-keyExchangeAlgorithm OID is overused in CMSKEA. In fact, the situation is slightly worse than what you describe. I added bullet 2 to your list as follows. 1. RFC2528: id-keyExchangeAlgorithm is used in a certificate to identify the algorithm type of the public key. The parameters field in this case is an OCTET STRING identifying the group parameters for the key. 2. CMSKEA, Sec 4.2, 3rd para: id-keyExchangeAlgorithm can be used in a keyAgreementRecipientInfo originatorKey to identify the type of the public key. The parameters field in this case is an OCTET STRING identifying the group parameters for the key. 3. CMSKEA, Sec 4.2.1, 4th para: id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo keyEncryptionAlgorithm field. In this case the parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID). 4. CMSKEA, Sec 4.3, 2nd para: id-keyExchangeAlgorithm is used in KEKRecipientInfo keyEncryptionAlgorithm field. In this case the parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID). I agree with your proposed change for CMSKEA, Sec 4.3, 2nd para. I don't agree with your proposed change for CMSKEA, Sec 4.2.1, 4th para, because it contradicts CMS section 12.3.1 which states: "Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm...fields. Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm ... fields." Recommend the following: 1) Continue to use the id-keyExchangeAlgorithm OID as stated in bullets 1 and 2 above. 2) Define a new OID for use as stated in bullet 3. Recommend the following OID be registered in the Registry of INFOSEC Technical Objects: id-kEA OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEA (23)}. The parameters field for this OID will be KeyWrapAlgorithm (using id-fortezzaWrap80 OID). 3) As you proposed, change CMSKEA, Sec 4.3, 2nd para to state that the id-fortezzaWrap80 OID (with NULL parameters) is used in KEKRecipientInfo keyEncryptionAlgorithm field. Please let me know if you agree with these recommendations. If anybody else has comments, please let me know. If there are no objections from anybody, then I will change the CMSKEA I-D to implement the aforementioned recommendations and I will apply for the new id-kEA OID. - John Pawling At 09:37 PM 4/29/99 -0700, Jim Schaad (Exchange) wrote: >John, > >I am having a big problem with the amount of overload going on for the the >OID id-keyExchangeAlgorithm. It appears to be used in three unique >locations in encoding an encrypted message and has different meanings and >two different set of parameters. > > >1. id-keyExchangeAlgorithm is used in a certificate to identify the >asymmetric algorithm. The parameters in this case are an OCTET STRING >identifing the group parameters for the key. > >2. id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo >keyEncryptionAlgorithm field. In this case the parameters is >KeyWrapAlgorithm (using id-fortezzaWrap80 as the algorithm). > >3. id-keyExchangeAlgorithm is used in KEKRecipientInfo >keyEncryptionAlgorithm field. In this case a completely different algorithm >is being referenced and again the parameters are KeyWrapAlgorithm. > > >I strong suggest that we change this as follows: > >1. id-keyExchangeAlgorithm is used in certificate w/parameters and in >KeyAgreementRecipeintInfo w/o parameters. > >2. id-fortezzaWrap80 is used in KEKRecipientInfo for the KEK algorithm >again w/o parameters are they are not needed. > >This should work unless we belive that there would ever be a different >content encryption algorithm for KEA. > > >jim > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00753 for ietf-smime-bks; Thu, 6 May 1999 10:30:43 -0700 (PDT) Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00749 for <ietf-smime@imc.org>; Thu, 6 May 1999 10:30:41 -0700 (PDT) Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id NAA04289 for <ietf-smime@imc.org>; Thu, 6 May 1999 13:39:39 -0400 (EDT) Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id NAA03557; Thu, 6 May 1999 13:36:27 -0400 Date: Thu, 6 May 1999 13:36:27 -0400 Message-Id: <199905061736.NAA03557@ajsn101.jgvandyke.com> X-Sender: jsp@ajsn101 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> From: jsp@jgvandyke.com (John Pawling) Subject: More Re: Comments on cmskea Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim and friends, Please substitute "id-kEAKeyEncryptionAlgorithm" for "id-KEA" in my earlier message. Also, change the definition to: "id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}. - John Pawling Previous message: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Jim, Thank you very much for your feedback regarding the "CMS KEA and SKIPJACK Conventions" (CMSKEA) I-D. I apologize for not answering your message sooner. I believe that you make an excellent point that the id-keyExchangeAlgorithm OID is overused in CMSKEA. In fact, the situation is slightly worse than what you describe. I added bullet 2 to your list as follows. 1. RFC2528: id-keyExchangeAlgorithm is used in a certificate to identify the algorithm type of the public key. The parameters field in this case is an OCTET STRING identifying the group parameters for the key. 2. CMSKEA, Sec 4.2, 3rd para: id-keyExchangeAlgorithm can be used in a keyAgreementRecipientInfo originatorKey to identify the type of the public key. The parameters field in this case is an OCTET STRING identifying the group parameters for the key. 3. CMSKEA, Sec 4.2.1, 4th para: id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo keyEncryptionAlgorithm field. In this case the parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID). 4. CMSKEA, Sec 4.3, 2nd para: id-keyExchangeAlgorithm is used in KEKRecipientInfo keyEncryptionAlgorithm field. In this case the parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID). I agree with your proposed change for CMSKEA, Sec 4.3, 2nd para. I don't agree with your proposed change for CMSKEA, Sec 4.2.1, 4th para, because it contradicts CMS section 12.3.1 which states: "Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm...fields. Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm ... fields." Recommend the following: 1) Continue to use the id-keyExchangeAlgorithm OID as stated in bullets 1 and 2 above. 2) Define a new OID for use as stated in bullet 3. Recommend the following OID be registered in the Registry of INFOSEC Technical Objects: id-kEA OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEA (23)}. The parameters field for this OID will be KeyWrapAlgorithm (using id-fortezzaWrap80 OID). 3) As you proposed, change CMSKEA, Sec 4.3, 2nd para to state that the id-fortezzaWrap80 OID (with NULL parameters) is used in KEKRecipientInfo keyEncryptionAlgorithm field. Please let me know if you agree with these recommendations. If anybody else has comments, please let me know. If there are no objections from anybody, then I will change the CMSKEA I-D to implement the aforementioned recommendations and I will apply for the new id-kEA OID. - John Pawling At 09:37 PM 4/29/99 -0700, Jim Schaad (Exchange) wrote: >John, > >I am having a big problem with the amount of overload going on for the the >OID id-keyExchangeAlgorithm. It appears to be used in three unique >locations in encoding an encrypted message and has different meanings and >two different set of parameters. > > >1. id-keyExchangeAlgorithm is used in a certificate to identify the >asymmetric algorithm. The parameters in this case are an OCTET STRING >identifing the group parameters for the key. > >2. id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo >keyEncryptionAlgorithm field. In this case the parameters is >KeyWrapAlgorithm (using id-fortezzaWrap80 as the algorithm). > >3. id-keyExchangeAlgorithm is used in KEKRecipientInfo >keyEncryptionAlgorithm field. In this case a completely different algorithm >is being referenced and again the parameters are KeyWrapAlgorithm. > > >I strong suggest that we change this as follows: > >1. id-keyExchangeAlgorithm is used in certificate w/parameters and in >KeyAgreementRecipeintInfo w/o parameters. > >2. id-fortezzaWrap80 is used in KEKRecipientInfo for the KEK algorithm >again w/o parameters are they are not needed. > >This should work unless we belive that there would ever be a different >content encryption algorithm for KEA. > > >jim > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA28352 for ietf-smime-bks; Thu, 6 May 1999 06:45:14 -0700 (PDT) Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28348 for <ietf-smime@imc.org>; Thu, 6 May 1999 06:45:12 -0700 (PDT) Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id JAA02750 for <ietf-smime@imc.org>; Thu, 6 May 1999 09:54:09 -0400 (EDT) Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id JAA01468; Thu, 6 May 1999 09:50:57 -0400 Date: Thu, 6 May 1999 09:50:57 -0400 Message-Id: <199905061350.JAA01468@ajsn101.jgvandyke.com> X-Sender: jsp@ajsn101 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Ietf-Smime (E-mail)" <ietf-smime@imc.org> From: jsp@jgvandyke.com (John Pawling) Subject: Re: Comments on cmskea Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Jim, Thank you very much for your feedback regarding the "CMS KEA and SKIPJACK Conventions" (CMSKEA) I-D. I apologize for not answering your message sooner. I believe that you make an excellent point that the id-keyExchangeAlgorithm OID is overused in CMSKEA. In fact, the situation is slightly worse than what you describe. I added bullet 2 to your list as follows. 1. RFC2528: id-keyExchangeAlgorithm is used in a certificate to identify the algorithm type of the public key. The parameters field in this case is an OCTET STRING identifying the group parameters for the key. 2. CMSKEA, Sec 4.2, 3rd para: id-keyExchangeAlgorithm can be used in a keyAgreementRecipientInfo originatorKey to identify the type of the public key. The parameters field in this case is an OCTET STRING identifying the group parameters for the key. 3. CMSKEA, Sec 4.2.1, 4th para: id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo keyEncryptionAlgorithm field. In this case the parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID). 4. CMSKEA, Sec 4.3, 2nd para: id-keyExchangeAlgorithm is used in KEKRecipientInfo keyEncryptionAlgorithm field. In this case the parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID). I agree with your proposed change for CMSKEA, Sec 4.3, 2nd para. I don't agree with your proposed change for CMSKEA, Sec 4.2.1, 4th para, because it contradicts CMS section 12.3.1 which states: "Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm...fields. Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm ... fields." Recommend the following: 1) Continue to use the id-keyExchangeAlgorithm OID as stated in bullets 1 and 2 above. 2) Define a new OID for use as stated in bullet 3. Recommend the following OID be registered in the Registry of INFOSEC Technical Objects: id-kEA OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEA (23)}. The parameters field for this OID will be KeyWrapAlgorithm (using id-fortezzaWrap80 OID). 3) As you proposed, change CMSKEA, Sec 4.3, 2nd para to state that the id-fortezzaWrap80 OID (with NULL parameters) is used in KEKRecipientInfo keyEncryptionAlgorithm field. Please let me know if you agree with these recommendations. If anybody else has comments, please let me know. If there are no objections from anybody, then I will change the CMSKEA I-D to implement the aforementioned recommendations and I will apply for the new id-kEA OID. - John Pawling At 09:37 PM 4/29/99 -0700, Jim Schaad (Exchange) wrote: >John, > >I am having a big problem with the amount of overload going on for the the >OID id-keyExchangeAlgorithm. It appears to be used in three unique >locations in encoding an encrypted message and has different meanings and >two different set of parameters. > > >1. id-keyExchangeAlgorithm is used in a certificate to identify the >asymmetric algorithm. The parameters in this case are an OCTET STRING >identifing the group parameters for the key. > >2. id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo >keyEncryptionAlgorithm field. In this case the parameters is >KeyWrapAlgorithm (using id-fortezzaWrap80 as the algorithm). > >3. id-keyExchangeAlgorithm is used in KEKRecipientInfo >keyEncryptionAlgorithm field. In this case a completely different algorithm >is being referenced and again the parameters are KeyWrapAlgorithm. > > >I strong suggest that we change this as follows: > >1. id-keyExchangeAlgorithm is used in certificate w/parameters and in >KeyAgreementRecipeintInfo w/o parameters. > >2. id-fortezzaWrap80 is used in KEKRecipientInfo for the KEK algorithm >again w/o parameters are they are not needed. > >This should work unless we belive that there would ever be a different >content encryption algorithm for KEA. > > >jim > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA23934 for ietf-smime-bks; Tue, 4 May 1999 14:13:37 -0700 (PDT) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23930 for <ietf-smime@imc.org>; Tue, 4 May 1999 14:13:36 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA04207; Tue, 4 May 1999 14:13:16 -0700 (PDT) Message-Id: <4.1.19990504171329.009da520@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 May 1999 17:13:59 -0400 To: William Ottaway <w.ottaway@eris.dera.gov.uk> From: Russ Housley <housley@spyrus.com> Subject: RE: Charter Revision Cc: "ietf-smime@imc.org" <ietf-smime@imc.org> In-Reply-To: <01BE9640.4BE191A0.w.ottaway@eris.dera.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Sorry, yes DOMSEC document shuld be included as Experimental work. Russ At 03:10 PM 5/4/99 +0100, William Ottaway wrote: >Russ, > >Should the domsec document be included? > >Bill > >-----Original Message----- >From: Russ Housley [SMTP:housley@spyrus.com] >Sent: Tuesday, May 04, 1999 2:58 AM >To: ietf-smime@imc.org >Subject: Charter Revision > >S/MIME WG: > >Now that the basic S/MIME v3 specifications have passed the IESG, it is >time to update the Working Group Charter. Several different documents >should be included: > > - Certificate Distribution (Standards track) > - CMS and ESS Examples (Standards track) > - Small Subgroup Attack (Infromational) > - Mail List Management (Standards track) > - ESS Security Labels (Informational) > - KEA & SKIPJACK Algorithms (Informational) > - IDEA Algorithm (Informational) > >Would the proponent for each area please provide me with a few sentences >for the updated Charter and the milestones. > >Are there any topics that I omitted? > >Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10546 for ietf-smime-bks; Tue, 4 May 1999 07:07:56 -0700 (PDT) Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10542 for <ietf-smime@imc.org>; Tue, 4 May 1999 07:07:54 -0700 (PDT) Received: (qmail 7689 invoked from network); 4 May 1999 14:09:57 -0000 Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 4 May 1999 14:09:57 -0000 Received: (qmail 2440 invoked from network); 4 May 1999 14:09:57 -0000 Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 4 May 1999 14:09:57 -0000 Received: by localhost with Microsoft MAPI; Tue, 4 May 1999 15:10:50 +0100 Message-ID: <01BE9640.4BE191A0.w.ottaway@eris.dera.gov.uk> From: William Ottaway <w.ottaway@eris.dera.gov.uk> To: "'Russ Housley'" <housley@spyrus.com>, "ietf-smime@imc.org" <ietf-smime@imc.org> Subject: RE: Charter Revision Date: Tue, 4 May 1999 15:10:49 +0100 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: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> Russ, Should the domsec document be included? Bill -----Original Message----- From: Russ Housley [SMTP:housley@spyrus.com] Sent: Tuesday, May 04, 1999 2:58 AM To: ietf-smime@imc.org Subject: Charter Revision S/MIME WG: Now that the basic S/MIME v3 specifications have passed the IESG, it is time to update the Working Group Charter. Several different documents should be included: - Certificate Distribution (Standards track) - CMS and ESS Examples (Standards track) - Small Subgroup Attack (Infromational) - Mail List Management (Standards track) - ESS Security Labels (Informational) - KEA & SKIPJACK Algorithms (Informational) - IDEA Algorithm (Informational) Would the proponent for each area please provide me with a few sentences for the updated Charter and the milestones. Are there any topics that I omitted? Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA09580 for ietf-smime-bks; Tue, 4 May 1999 06:15:28 -0700 (PDT) Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA09576 for <ietf-smime@imc.org>; Tue, 4 May 1999 06:15:28 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.66.108.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA24501 for <ietf-smime@imc.org>; Tue, 4 May 1999 06:15:01 -0700 (PDT) Message-Id: <4.1.19990503212856.009dc630@mail.spyrus.com> Message-Id: <4.1.19990503212856.009dc630@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 03 May 1999 21:58:17 -0400 To: ietf-smime@imc.org From: Russ Housley <housley@spyrus.com> Subject: Charter Revision Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> S/MIME WG: Now that the basic S/MIME v3 specifications have passed the IESG, it is time to update the Working Group Charter. Several different documents should be included: - Certificate Distribution (Standards track) - CMS and ESS Examples (Standards track) - Small Subgroup Attack (Infromational) - Mail List Management (Standards track) - ESS Security Labels (Informational) - KEA & SKIPJACK Algorithms (Informational) - IDEA Algorithm (Informational) Would the proponent for each area please provide me with a few sentences for the updated Charter and the milestones. Are there any topics that I omitted? Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA22346 for ietf-smime-bks; Sun, 2 May 1999 05:19:24 -0700 (PDT) Received: from orange.one.net.au (orange.one.net.au [203.17.224.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22311; Sun, 2 May 1999 05:13:43 -0700 (PDT) From: stockinvest234@yahoo.com Received: from d5y9r2 ([202.139.11.74]) by orange.one.net.au (8.8.8+Sun/8.8.8) with SMTP id VAA28090; Sun, 2 May 1999 21:52:34 +1000 (EST) Date: Sun, 2 May 1999 21:52:34 +1000 (EST) Message-Id: <199905021152.VAA28090@orange.one.net.au> To: stockinvestor@stocksite.com Subject: Total Profit +980% in 1998!!! Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> ================================== Our 1998 Stock Picks - Total Profit +980%!!! ================================== Subscribe to our Newsletter to be Informed of our Stock Picks - 100% FREE!!! VALUE stocks with outstanding company news AND upcoming extensive promotion are virtually GUARANTEED profits - you only need an early stock purchase to profit. Our total profit for 1998 was +980%!!! Subscribe to our FREE newsletter, and we'll notify you of stocks we've selected - this is where we put OUR money! We ALSO provide links to information confirming our research is ACCURATE, enabling you to make informed decisions regarding stocks. This is one opportunity too good to miss . . . and it's completely FREE!!! To Subscribe FREE, please visit http://home1.gte.net/web22bbx/stocks10.htm NOTE: This is a one-time mailing. If the site is busy or down, please try again later Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA19821 for ietf-smime-bks; Sat, 1 May 1999 09:16:29 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA19817 for <ietf-smime@imc.org>; Sat, 1 May 1999 09:16:27 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA11563 for <ietf-smime@imc.org>; Sat, 1 May 1999 18:18:16 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Sat, 1 May 1999 18:18:16 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA21038 for <ietf-smime@imc.org>; Sat, 1 May 1999 18:18:15 +0200 From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA11513 for ietf-smime@imc.org; Sat, 1 May 1999 18:18:15 +0200 Date: Sat, 1 May 1999 18:18:15 +0200 Message-Id: <199905011618.SAA11513@emeriau.edelweb.fr> To: ietf-smime@imc.org Subject: RE: nonRepudiation key usage in SSL and S/MIME Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-smime/mail-archive/> List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe> > Pleased to see someone else bring this up; I've just been writing > some documentation on our new S/MIME 3 toolkit, from a position of > relative unfamiliarity with the ESS services, and this really stuck > out like a sore thumb for me. I think it may have been an error to > put the automatic generation of receipts as a MUST without addressing > this problem. It may be worth raising on the list, despite the late > stage we're at in the proceedings. > Sending receipts in an automatic way is a strange implemenation. The problem is at 15 years old, and lot's of text has been written about it. In the model that was borrowed from X.420, nothiing is said about when a receipt is generated. In any case, a receipt notification is just a specially formatted message. people have fortunalety given up to specify requirement about when these things should be generated. The common misunderstanding is that people talk about 'read notification' and an analogy of the postal service with registered letters with receipt. It is understandable that such a kind of service may be desirable, but then the underlying model is wrong. The postal service just gives the originator an indication that some letter has been received but nothing about the contents. IMHO a receipt is a conscious act from a user who wants to indicate the reception/refusal of a message; the creation of a receipt is by no means related to the action of reading a message for the first time. At any time a user should be able to generate or not a receipt. Whether the receipt has just informational character or more depends on the context. If one reads carefully the ess text, a lot is about about 'validation' of the receipt request. This validation includes what? At least, the validation of the 'signatures' on the receipt request, thus all kinds of certificate path handling etc; a local policy can decide, we don't accept signatures from anyone on these types of messages. Validation of a signature does not necessarily occur at reading time. This should also be a conscious act of the user, since it may involve network interactions (OCSP calls or others). And also: SPAM, SPAM, SPAM. If I had to use a tool kit that generates such a stuff, the first thing would be to stop my outgoing mail, and delete the stuff before it gets sent. Inside a closed environment that uses a mail based application, the situation may be different, but in this case it should still be the application that decides when and how to create a receipt, and never whatever an underlying mail tool kit as an automatic result of a transfer of the message to the application. Of course, some may have a another philosophy. :-) The type of certificate used is still another question. Peter
- New SMime Capabilities item Jim Schaad (Exchange)
- Re: New SMime Capabilities item Russ Housley
- RE: New SMime Capabilities item Jim Schaad (Exchange)
- RE: New SMime Capabilities item Russ Housley
- RE: New SMime Capabilities item Blake Ramsdell