Re: ASN.1 Usage In S/MIME

["Housley, Russ" <[e-mail]>]

Please take a look at RFCs 3369, 3370, 2632, 2633, and 2634.  You will see 
that ASN.1 is used for certificates and PKCS#7 (which we call CMS).

Signatures generally cover the MEME-encoded content as well as signed 
attributes.  Each of the these attributes is specified in ASN.1.

Russ


At 05:45 PM 9/28/2002 -0500, Phil Smiley wrote:
>My company is evaluating a number of options for deployment of AS2 in our 
>product.  In one of our evaluation meetings, it was said that care must be 
>taken when choosing the correct S/MIME toolkit because of the dependence 
>that S/MIME has on ASN.1 and the complications that introduces.
>
>I can accept that certificates and related cryptographic materials are DER 
>or BER encoded but I would expect that to be done by a cryptographic 
>toolkit from RSA, Baltimore Technologies, Certicom, etc.   I would not 
>expect this to be value added by an S/MIME toolkit.
>
>Beyond the PKCS standards, where does S/MIME utilize ASN.1?
>
>Specific to AS2, are there other parts of that spec that call for ASN.1?
>
>Thank you;  Phil Smiley



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8UDq6Y19454 for ietf-smime-bks; Mon, 30 Sep 2002 06:52:06 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8UDq5v19450 for <[e-mail]>; Mon, 30 Sep 2002 06:52:05 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Sep 2002 13:52:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA16155 for <[e-mail]>; Mon, 30 Sep 2002 09:52:05 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8UDnZQ27643 for <[e-mail]>; Mon, 30 Sep 2002 09:49:35 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV5FG4>; Mon, 30 Sep 2002 09:51:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.28]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV5FGN; Mon, 30 Sep 2002 09:51:45 -0400
From: "Housley, Russ" <[e-mail]>
To: Phil Smiley <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 30 Sep 2002 09:47:04 -0400
Subject: Re: ASN.1 Usage In S/MIME
In-Reply-To: <02bc01c26740$cfa06b40$6401a8c0@bohr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please take a look at RFCs 3369, 3370, 2632, 2633, and 2634.  You will see 
that ASN.1 is used for certificates and PKCS#7 (which we call CMS).

Signatures generally cover the MEME-encoded content as well as signed 
attributes.  Each of the these attributes is specified in ASN.1.

Russ


At 05:45 PM 9/28/2002 -0500, Phil Smiley wrote:
>My company is evaluating a number of options for deployment of AS2 in our 
>product.  In one of our evaluation meetings, it was said that care must be 
>taken when choosing the correct S/MIME toolkit because of the dependence 
>that S/MIME has on ASN.1 and the complications that introduces.
>
>I can accept that certificates and related cryptographic materials are DER 
>or BER encoded but I would expect that to be done by a cryptographic 
>toolkit from RSA, Baltimore Technologies, Certicom, etc.   I would not 
>expect this to be value added by an S/MIME toolkit.
>
>Beyond the PKCS standards, where does S/MIME utilize ASN.1?
>
>Specific to AS2, are there other parts of that spec that call for ASN.1?
>
>Thank you;  Phil Smiley


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8T5Q9v19517 for ietf-smime-bks; Sat, 28 Sep 2002 22:26:09 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8T5Q4v19513 for <[e-mail]>; Sat, 28 Sep 2002 22:26:04 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8T5Pn4b029272; Sun, 29 Sep 2002 17:25:49 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA521108; Sun, 29 Sep 2002 17:25:44 +1200 (NZST) (sender [e-mail])
Date: Sun, 29 Sep 2002 17:25:44 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  ASN.1 Usage In S/MIME
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Phil Smiley" <[e-mail]> writes:

>My company is evaluating a number of options for deployment of AS2 in our
>product.  In one of our evaluation meetings, it was said that care must be
>taken when choosing the correct S/MIME toolkit because of the dependence that
>S/MIME has on ASN.1 and the complications that introduces.

Given that any vendor which plays in this area has (presumably) done
reasonable interop testing, there isn't much in the way of complications,
unless you're using oddball/obscure features.  When I looked at it a few years
back using standard signed/encrypted data, the code I was using worked out of
the box with the apps I tried it with (Outlook/Netscape/whatever Tumbleweed's
one was called then/etc).

(Having said that, I've seen a few homebrew implementations from Europe
 deployed in vertical-market applications (e.g. your CA also sells you the
 software you use, and you can't talk to anyone else) where the vendor never
 did any interop testing and the data formatting is often surprising, but
 that's the exception rather than the rule).

>I can accept that certificates and related cryptographic materials are DER or
>BER encoded but I would expect that to be done by a cryptographic toolkit
>from RSA, Baltimore Technologies, Certicom, etc.   I would not expect this to
>be value added by an S/MIME toolkit.

There's no difference between a "crypto toolkit" (which does the PKCS #7/CMS
data format) and an "S/MIME toolkit", S/MIME is just PKCS #7/CMS with base64-
encoding.  In other words, you use a crypto toolkit to do PKCS #7/CMS, and an
MUA/MTA to do the MIME part.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8SMgwB26606 for ietf-smime-bks; Sat, 28 Sep 2002 15:42:58 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SMgvv26602 for <[e-mail]>; Sat, 28 Sep 2002 15:42:57 -0700 (PDT)
Received: from bohr ([12.237.30.69]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020928224255.DBDP5955.rwcrmhc51.attbi.com@bohr> for <[e-mail]>; Sat, 28 Sep 2002 22:42:55 +0000
Message-ID: <02bc01c26740$cfa06b40$6401a8c0@bohr>
From: "Phil Smiley" <[e-mail]>
To: <[e-mail]>
Subject: ASN.1 Usage In S/MIME
Date: Sat, 28 Sep 2002 17:45:57 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B9_01C26716.E69374C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_02B9_01C26716.E69374C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My company is evaluating a number of options for deployment of AS2 in =
our product.  In one of our evaluation meetings, it was said that care =
must be taken when choosing the correct S/MIME toolkit because of the =
dependence that S/MIME has on ASN.1 and the complications that =
introduces.

I can accept that certificates and related cryptographic materials are =
DER or BER encoded but I would expect that to be done by a cryptographic =
toolkit from RSA, Baltimore Technologies, Certicom, etc.   I would not =
expect this to be value added by an S/MIME toolkit.

Beyond the PKCS standards, where does S/MIME utilize ASN.1?

Specific to AS2, are there other parts of that spec that call for ASN.1?

Thank you;  Phil Smiley

------=_NextPart_000_02B9_01C26716.E69374C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>My company is evaluating a number of =
options for=20
deployment of AS2 in our product.&nbsp; In one of our evaluation =
meetings, it=20
was said that care must be taken when choosing the correct S/MIME =
toolkit=20
because of the dependence that S/MIME has on ASN.1 and the complications =
that=20
introduces.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I can accept that certificates and =
related=20
cryptographic materials are DER or BER encoded but I would expect that =
to be=20
done by a cryptographic toolkit from RSA, Baltimore Technologies, =
Certicom,=20
etc.&nbsp;&nbsp; I would not expect this to be value added by an S/MIME=20
toolkit.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Beyond the PKCS standards, where does =
S/MIME=20
utilize ASN.1?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Specific to AS2, are there other parts =
of that spec=20
that call for ASN.1?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you;&nbsp; Phil=20
Smiley</FONT></DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_02B9_01C26716.E69374C0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8QCatR07472 for ietf-smime-bks; Thu, 26 Sep 2002 05:36:55 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QCasv07465 for <[e-mail]>; Thu, 26 Sep 2002 05:36:54 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04495; Thu, 26 Sep 2002 08:35:01 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-08.txt
Date: Thu, 26 Sep 2002 08:35:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-08.txt
	Pages		: 8
	Date		: 2002-9-25
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-examples-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-examples-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-examples-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-examples-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8N9mxC29088 for ietf-smime-bks; Mon, 23 Sep 2002 02:48:59 -0700 (PDT)
Received: from blooper.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8N9mwv29084 for <[e-mail]>; Mon, 23 Sep 2002 02:48:58 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g8N9mftA009401 for <[e-mail]>; Mon, 23 Sep 2002 11:48:52 +0200 (MEST)
Message-ID: <008e01c262e5$80c5e180$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: X/MIME Anybody?
Date: Mon, 23 Sep 2002 11:42:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The subject refers to an XML DSig version of S/MIME that
I wonder if anybody is working with.

Anders



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KDpSi12023 for ietf-smime-bks; Fri, 20 Sep 2002 06:51:28 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8KDpQk12019 for <[e-mail]>; Fri, 20 Sep 2002 06:51:26 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Sep 2002 13:51:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA28963 for <[e-mail]>; Fri, 20 Sep 2002 09:51:27 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8KDn3810933 for <[e-mail]>; Fri, 20 Sep 2002 09:49:03 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <SV20BDL0>; Fri, 20 Sep 2002 14:55:07 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.36]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVW3QQ; Fri, 20 Sep 2002 09:51:18 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 20 Sep 2002 09:51:08 -0400
To: [e-mail], [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: PKCS #1 v2.1 Internet-Draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKCS #1 v2.1 has been published as an Internet-Draft at
http://www.ietf.org/internet-drafts/draft-jonsson-pkcs1-v2dot1-00.txt.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IIEmO06664 for ietf-smime-bks; Wed, 18 Sep 2002 11:14:48 -0700 (PDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IIElk06658; Wed, 18 Sep 2002 11:14:47 -0700 (PDT)
Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IIEiP18605; Wed, 18 Sep 2002 11:14:44 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IIEhR18587; Wed, 18 Sep 2002 11:14:43 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8IIEhO23413; Wed, 18 Sep 2002 12:14:43 -0600 (MDT)
Received: from dhcp-east-2op4-5-130-35-47-95.us.oracle.com by rgmum4.us.oracle.com with ESMTP id 65429241032372882; Wed, 18 Sep 2002 12:14:42 -0600
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:17:49 -0700
From: Himanshu Chatterjee <[e-mail]>
Organization: Server Technologies
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: Steve Hanna <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
References: <[e-mail]> <00f201c25eef$42ac7bb0$2308a8c0@MJDeskproEN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

May be also an issue for those who depend on ldap 'mail' attribute and by
protocol ldap's data is case insensitive.  Himanshu

Marc Jadoul wrote:

> Seems a BIG problem to me!
>
> May be RFC 3280 is wrong in his understanding of RFC 822.
> But RFC 822 (or ...) is probably wrong in doing things so complex for End
> Users.
> And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
>
> Why is it like this in RFC 822 and successor?
>
> Marc Jadoul
>
> ----- Original Message -----
> From: "Steve Hanna" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Tuesday, September 17, 2002 11:23 PM
> Subject: RFC 3280 error WRT rfc822Name
>
> >
> > In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
> >
> >    Note that while upper and lower case letters are allowed in an
> >    RFC 822 addr-spec, no significance is attached to the case.
> >
> > But RFC 822 says:
> >
> >         The only syntactic units which requires preservation of
> >         case information are:
> >
> >                     -  text
> >                     -  qtext
> >                     -  dtext
> >                     -  ctext
> >                     -  quoted-pair
> >                     -  local-part, except "Postmaster"
> >
> >         When matching any other syntactic unit, case is to be ignored.
> >
> > And RFC 2821 (the successor to RFC 821 and the companion
> > to RFC 2822, which obsoletes RFC 822) is more explicit:
> >
> >    The local-part of a mailbox MUST BE treated as case sensitive.
> >
> > I have spoken to a few people about this and the consensus
> > seems to be that RFC 3280 is wrong. When matching email
> > addresses (such as when processing name constraints during
> > certificate path validation), the local-part component of
> > an email address must be treated as case-sensitive.
> >
> > If the members of these lists don't agree with this analysis,
> > please speak up. Otherwise, I expect that this will be fixed
> > in the successor to RFC 3280. Note that I don't think this
> > is an especially big deal. I just thought people would want
> > to know of the problem ASAP.
> >
> > Note also that many email servers don't treat local-part as
> > case-sensitive. But some do. There's no way for a certificate
> > processing system to know whether [e-mail] is
> > actually the same mailbox as [e-mail]. So the
> > certificate processing system must treat them as different.
> > At least, that's the rationale for this rule.
> >
> > Thanks,
> >
> > Steve Hanna
> > Sun Microsystems, Inc.
> >



Received: by above.proper.com (8.11.6/8.11.3) id g8HNa1L15675 for ietf-smime-bks; Tue, 17 Sep 2002 16:36:01 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HNXOk15635; Tue, 17 Sep 2002 16:33:24 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 17 Sep 2002 16:33:22 -0700 (PDT)
Date: Tue, 17 Sep 2002 16:27:58 -0700 (PDT)
From: [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
In-reply-to: "Your message dated Tue, 17 Sep 2002 15:36:59 -0700" <[e-mail]>
To: [e-mail]
Cc: Steve Hanna <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> That's pretty interesting....I hope I'm the only one surprised by this
> requirement.

This requirement is well understood by those of us who work on email software.
Any package that fails to support it gets in trouble sooner or later. Indeed,
software that preserves case but isn't capable of supporting case sensitivity
for domains it has administrative control over can be problematic. I've seen
software sales won or lost over this issue.

>  At the end of the same paragraph in RFC 2821 is the
> "loophole" that I think most people will invoke to get around this new
> "requirement":

> ...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

> I anticipate that this means, for all practical matters, that the "MUST"
> part of case sensitivity will be ignored by enough vendors that we
> should plan on treating the mail local-part as case insensitive anyhow.
>  Personally, I think it makes sense to treat mailbox strings as case
> insensitive, but that's just me speaking.

The rule is fairly simple: If you have administrative authority for the domain
you are entitled to use the local-part in any way you like, including but not
limited to igoring case. If, on the other hand, you do not have administrative
authority, you are not entitled to do this. And if you do, know that there real
domain exist where case matters and things will break.

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HMb5H14160 for ietf-smime-bks; Tue, 17 Sep 2002 15:37:05 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HMb3k14156; Tue, 17 Sep 2002 15:37:03 -0700 (PDT)
Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8HLlTm20859; Tue, 17 Sep 2002 14:47:29 -0700 (PDT)
Received: from obob.netscape.com ([207.200.73.215]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2LTHO00.RGR; Tue, 17 Sep 2002 15:37:00 -0700 
Received: from netscape.com ([64.236.139.249]) by obob.netscape.com (Netscape Messaging Server 4.15) with ESMTP id H2LTFR00.GQX; Tue, 17 Sep 2002 15:35:51 -0700 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 15:36:59 -0700
From: [e-mail] (Bill Burns)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:

>In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
>
>   Note that while upper and lower case letters are allowed in an
>   RFC 822 addr-spec, no significance is attached to the case.
>
>But RFC 822 says:
>
>        The only syntactic units which requires preservation of
>        case information are:
>
>                    -  text
>                    -  qtext
>                    -  dtext
>                    -  ctext
>                    -  quoted-pair
>                    -  local-part, except "Postmaster"
>
>        When matching any other syntactic unit, case is to be ignored.
>
>And RFC 2821 (the successor to RFC 821 and the companion
>to RFC 2822, which obsoletes RFC 822) is more explicit:
>
>   The local-part of a mailbox MUST BE treated as case sensitive.
>
>I have spoken to a few people about this and the consensus
>seems to be that RFC 3280 is wrong. When matching email
>addresses (such as when processing name constraints during
>certificate path validation), the local-part component of
>an email address must be treated as case-sensitive.
>
>If the members of these lists don't agree with this analysis,
>please speak up. Otherwise, I expect that this will be fixed
>in the successor to RFC 3280. Note that I don't think this
>is an especially big deal. I just thought people would want
>to know of the problem ASAP.
>
>Note also that many email servers don't treat local-part as
>case-sensitive. But some do. There's no way for a certificate
>processing system to know whether [e-mail] is
>actually the same mailbox as [e-mail]. So the
>certificate processing system must treat them as different.
>At least, that's the rationale for this rule.
>
>Thanks,
>
>Steve Hanna
>Sun Microsystems, Inc.
>  
>
Thanks, Steve.

That's pretty interesting....I hope I'm the only one surprised by this 
requirement.  At the end of the same paragraph in RFC 2821 is the 
"loophole" that I think most people will invoke to get around this new 
"requirement":

...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

I anticipate that this means, for all practical matters, that the "MUST" 
part of case sensitivity will be ignored by enough vendors that we 
should plan on treating the mail local-part as case insensitive anyhow. 
 Personally, I think it makes sense to treat mailbox strings as case 
insensitive, but that's just me speaking.

bill





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HLXGB09321 for ietf-smime-bks; Tue, 17 Sep 2002 14:33:16 -0700 (PDT)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HLSnk09087; Tue, 17 Sep 2002 14:28:49 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14385; Tue, 17 Sep 2002 14:28:46 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id RAA02253; Tue, 17 Sep 2002 17:28:45 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 17:23:52 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: RFC 3280 error WRT rfc822Name
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In section 4.2.1.7, RFC 3280 (and RFC 2459) says:

   Note that while upper and lower case letters are allowed in an
   RFC 822 addr-spec, no significance is attached to the case.

But RFC 822 says:

        The only syntactic units which requires preservation of
        case information are:

                    -  text
                    -  qtext
                    -  dtext
                    -  ctext
                    -  quoted-pair
                    -  local-part, except "Postmaster"

        When matching any other syntactic unit, case is to be ignored.

And RFC 2821 (the successor to RFC 821 and the companion
to RFC 2822, which obsoletes RFC 822) is more explicit:

   The local-part of a mailbox MUST BE treated as case sensitive.

I have spoken to a few people about this and the consensus
seems to be that RFC 3280 is wrong. When matching email
addresses (such as when processing name constraints during
certificate path validation), the local-part component of
an email address must be treated as case-sensitive.

If the members of these lists don't agree with this analysis,
please speak up. Otherwise, I expect that this will be fixed
in the successor to RFC 3280. Note that I don't think this
is an especially big deal. I just thought people would want
to know of the problem ASAP.

Note also that many email servers don't treat local-part as
case-sensitive. But some do. There's no way for a certificate
processing system to know whether [e-mail] is
actually the same mailbox as [e-mail]. So the
certificate processing system must treat them as different.
At least, that's the rationale for this rule.

Thanks,

Steve Hanna
Sun Microsystems, Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DIquU09088 for ietf-smime-bks; Fri, 13 Sep 2002 11:52:56 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DIqsk09083 for <[e-mail]>; Fri, 13 Sep 2002 11:52:54 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-228.hrz.uni-bielefeld.de [129.70.36.228]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Fri, 13 Sep 2002 20:52:54 +0200 (MET DST)
Date: Fri, 13 Sep 2002 20:50:01 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: Multipart non-clearsigned messages possible?
In-reply-to: <[e-mail]>
To: Elanor Foley <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_5PKk1/dSOdadl5d1wj10Kw)"
User-Agent: KMail/1.4.7
X-PGP-Key: 0xBDBFE838
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary_(ID_5PKk1/dSOdadl5d1wj10Kw)
Content-type: multipart/signed; name=" ";
 boundary="Boundary-02=_ZNjg9on56hqD21n"; micalg=pgp-sha1;
 protocol="application/pgp-signature"; charset=us-ascii
Content-disposition: inline; filename=" "
Content-transfer-encoding: 7bit

--Boundary-02=_ZNjg9on56hqD21n
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 09 September 2002 12:40, Elanor Foley wrote:
> Hello all,
>
> This may seem like a silly question, but is it possible to have a
> multipart, non-clearsigned s/mime message?
<snip>

If I understand you correctly, it is.

> b) it's possible: some part(s) of the message get signed, other
> parts, e.g. audio file, can be attached without being signed. The
> verification is only computed across the eContent inside the
> signedData anyway.

Yes, there are mechnisms for only signing some body parts.

> If b), does anyone know of an example I could look at (incl.
> headers)?

This isn't S/MIME, but OpenPGP, but the mechanics is the same: What I=20
write _here_ is signed, while...




--Boundary-02=_ZNjg9on56hqD21n
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9gjNZ3oWD+L2/6DgRApf+AKCvNRTYgxmFovw23aD6qYbROpmdFQCgo/Bb
+UQheF7fmxL/nh3JxnvyOrM=
=QJS/
-----END PGP SIGNATURE-----

--Boundary-02=_ZNjg9on56hqD21n--

--Boundary_(ID_5PKk1/dSOdadl5d1wj10Kw)
Content-type: text/plain; name="body part"; charset=us-ascii
Content-disposition: inline; filename="body part"
Content-transfer-encoding: quoted-printable

=2E..this is not.
>
> ---------------------------------------------------------------------
>-------- The information contained in this message is confidential and
> is intended for the addressee(s) only.  If you have received this
> message in error or there are any problems please notify the
> originator immediately.  The unauthorised use, disclosure, copying or
> alteration of this message is strictly forbidden. Baltimore
> Technologies plc will not be liable for direct, special, indirect or
> consequential damages arising from alteration of the contents of this
> message by a third party or as a result of any virus being passed on.
>
> This footnote confirms that this email message has been swept for
> Content Security threats, including computer viruses.
> http://www.baltimore.com

=2D-=20
Mutig warf sich die kleine =DCberwachungskamera zwischen T=E4ter und Opfer!
                                        --Rena Tangens / FoeBuD e.V.

--Boundary_(ID_5PKk1/dSOdadl5d1wj10Kw)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CCClE25499 for ietf-smime-bks; Thu, 12 Sep 2002 05:12:47 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CCCkk25495 for <[e-mail]>; Thu, 12 Sep 2002 05:12:46 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Query
Date: Thu, 12 Sep 2002 08:12:40 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Query
Thread-Index: AcJU+1xnhSPxjw0US260XRLWXeMNDAFWdxRA
From: "Nicholas, Richard" <[e-mail]>
To: "Vijay Raj" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8CCCkk25496
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Vijay,

> Hello,
>      Can anyone suggest me where to get the SMIME reference code
> 
> Regards
>  Vijay

The Getronics-developed reference implementation is available at:
http://www.getronicsgov.com/hot/sfl_home.htm

- Rich
---------------------------
Richard E. Nicholas
Principal Secure Systems Engineer
Getronics Government Solutions, LLC
[e-mail]
[phone]


Received: by above.proper.com (8.11.6/8.11.3) id g8C4jEx05993 for ietf-smime-bks; Wed, 11 Sep 2002 21:45:14 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8C4jCk05987 for <[e-mail]>; Wed, 11 Sep 2002 21:45:12 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Sep 2002 04:45:16 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id AAA26125 for <[e-mail]>; Thu, 12 Sep 2002 00:45:15 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8C4gtq22344 for <[e-mail]>; Thu, 12 Sep 2002 00:42:55 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVS8NM>; Thu, 12 Sep 2002 00:45:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.9.13 [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVS8NL; Thu, 12 Sep 2002 00:45:12 -0400
From: "Housley, Russ" <[e-mail]>
To: Vijay Raj <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 11 Sep 2002 20:20:17 -0400
Subject: Re: Query
In-Reply-To: <00e201c254f2$f1e23db0$8502a8c0@hellosoftdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I suggest you contact John Pawling ([e-mail]).

Russ


At 09:13 PM 9/5/2002 +0530, Vijay Raj wrote:
>Hello,
>          Can anyone suggest me where to get the SMIME reference code
>
>Regards
>  Vijay


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8B4MDW15383 for ietf-smime-bks; Tue, 10 Sep 2002 21:22:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8B4MBk15379 for <[e-mail]>; Tue, 10 Sep 2002 21:22:11 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Sep 2002 04:22:15 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id AAA27489 for <[e-mail]>; Wed, 11 Sep 2002 00:22:14 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8B4Jsv29655 for <[e-mail]>; Wed, 11 Sep 2002 00:19:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVSPCG>; Wed, 11 Sep 2002 00:22:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVSPC1; Wed, 11 Sep 2002 00:22:11 -0400
From: "Housley, Russ" <[e-mail]>
To: Elanor Foley <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 10 Sep 2002 18:58:58 -0400
Subject: Re: Multipart non-clearsigned messages possible?
In-Reply-To: <[e-mail] e.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
While the protocol support the signing of arbitrary MIME objects, it
would be quite difficult to write a mail client user interface that
allows the user to select a subset of the message to be covered by the
signature.&nbsp; So, in practice, we have seen sign-it/do-not-sign-it as
the user interface.<br><br>
That said, I think that it is very likely that application-to-application
communications will be developed that encrypt and sign selected portions
of a larger data transfer.&nbsp; I think this is likely because there is
not a user interface issue.<br><br>
Russ<br><br>
<br>
At 11:40 AM 9/9/2002 +0100, Elanor Foley wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Hello
all,<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">This may seem like a silly
question, but is it possible to have a multipart, non-clearsigned s/mime
message?<br>
My current thinking is<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">a) it's not possible: the whole
message gets signed, including attachments.<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">b) it's possible: some part(s)
of the message get signed, other parts, e.g. audio file, can be attached
without being signed. The verification is only computed across the
eContent inside the signedData anyway.<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If b), does anyone know of an
example I could look at (incl. headers)?<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Thanks,<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">&nbsp;-
Lnr</font></blockquote></html>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g89AkLH07354 for ietf-smime-bks; Mon, 9 Sep 2002 03:46:21 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89AkJk07350 for <[e-mail]>; Mon, 9 Sep 2002 03:46:20 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g89AYPI06535 for <[e-mail]>; Mon, 9 Sep 2002 11:34:25 +0100
Received: from  ([10.153.25.53]) by Baltimore-FW1; Mon, 09 Sep 2002 11:44:41 +0100 (BST)
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 9 Sep 2002 11:39:03 +0100
Received: from  ([10.153.25.10]) by Baltimore-FW1; Mon, 09 Sep 2002 11:44:38 +0100 (BST)
Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA21279 for <[e-mail]>; Mon, 9 Sep 2002 11:46:04 +0100
Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <P8RXMRN4>; Mon, 9 Sep 2002 11:50:04 +0100
Message-ID: <[e-mail]>
From: Elanor Foley <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Multipart non-clearsigned messages possible?
Date: Mon, 9 Sep 2002 11:40:15 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C257ED.48AD0740"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C257ED.48AD0740
Content-Type: text/plain; charset="iso-8859-1"

Hello all,
 
This may seem like a silly question, but is it possible to have a multipart,
non-clearsigned s/mime message?
My current thinking is
 
a) it's not possible: the whole message gets signed, including attachments.
 
b) it's possible: some part(s) of the message get signed, other parts, e.g.
audio file, can be attached without being signed. The verification is only
computed across the eContent inside the signedData anyway.
 
If b), does anyone know of an example I could look at (incl. headers)?
 
Thanks,
 
 - Lnr

 



-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com


------_=_NextPart_001_01C257ED.48AD0740
Content-Type: text/html; charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4912.300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff size=2>Hello 
all,</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff size=2>This 
may seem like a silly question, but is it possible to have a multipart, 
non-clearsigned s/mime message?</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff size=2>My 
current thinking is</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff size=2>a) 
it's not possible: the whole message gets signed, including 
attachments.</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff size=2>b) 
it's possible: some part(s) of the message get signed, other parts, e.g. audio 
file,&nbsp;can be&nbsp;attached without being signed. The verification is only 
computed across the eContent inside the signedData anyway.</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff size=2>If b), 
does anyone know of an example I could look at (incl. 
headers)?</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=989483610-09092002><FONT face=Arial color=#0000ff 
size=2>&nbsp;- Lnr</FONT></SPAN></DIV>
<BLOCKQUOTE><CODE><FONT size=3><FONT face=Tahoma 
size=2></FONT>&nbsp;</BLOCKQUOTE></FONT></CODE><CODE><FONT SIZE=3><BR>
<BR>
-----------------------------------------------------------------------------<BR>
The information contained in this message is confidential and is intended<BR>
for the addressee(s) only.  If you have received this message in error or<BR>
there are any problems please notify the originator immediately.  The <BR>
unauthorised use, disclosure, copying or alteration of this message is <BR>
strictly forbidden. Baltimore Technologies plc will not be liable for<BR>
direct, special, indirect or consequential damages arising from alteration<BR>
of the contents of this message by a third party or as a result of any <BR>
virus being passed on.<BR>
<BR>
This footnote confirms that this email message has been swept for Content<BR>
Security threats, including computer viruses.<BR>
http://www.baltimore.com<BR>
</FONT></CODE>
</BODY></HTML>

------_=_NextPart_001_01C257ED.48AD0740--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85GrRM03101 for ietf-smime-bks; Thu, 5 Sep 2002 09:53:27 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85GrQ203095 for <[e-mail]>; Thu, 5 Sep 2002 09:53:26 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g85GrJD18290; Thu, 5 Sep 2002 09:53:20 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3370 on Cryptographic Message Syntax (CMS) Algorithms
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 05 Sep 2002 09:53:19 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3370

        Title:	    Cryptographic Message Syntax (CMS) Algorithms
        Author(s):  R. Housley
        Status:	    Standards Track
	Date:       August 2002
        Mailbox:    [e-mail]
        Pages:      24
        Characters: 51001
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-cmsalg-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3370.txt


This document describes the conventions for using several
cryptographic algorithms with the Cryptographic Message Syntax
(CMS).  The CMS is used to digitally sign, digest, authenticate, or
encrypt arbitrary message contents.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This is now a Proposed Standard.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3370

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3370.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85GpFt02768 for ietf-smime-bks; Thu, 5 Sep 2002 09:51:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85GpE202762 for <[e-mail]>; Thu, 5 Sep 2002 09:51:14 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g85Gp9D16392; Thu, 5 Sep 2002 09:51:09 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3369 on Cryptographic Message Syntax (CMS)
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 05 Sep 2002 09:51:09 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3369

        Title:	    Cryptographic Message Syntax (CMS)
        Author(s):  R. Housley
        Status:	    Standards Track
	Date:       August 2002
        Mailbox:    [e-mail]
        Pages:      52
        Characters: 113975
        Obsoletes:  2630, 3211

        I-D Tag:    draft-ietf-smime-rfc2630bis-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3369.txt


This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This is now a Proposed Standard Protcol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3369

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3369.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: by above.proper.com (8.11.6/8.11.3) id g85Fg1500176 for ietf-smime-bks; Thu, 5 Sep 2002 08:42:01 -0700 (PDT)
Received: from hyd.hellosoft.com ([202.153.32.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85Ffv200167 for <[e-mail]>; Thu, 5 Sep 2002 08:41:58 -0700 (PDT)
Received: from vijayraj (router2.hyd.hellosoft.com [202.153.32.130]) by hyd.hellosoft.com (8.11.0/1.03) with SMTP id g85Fgcg28071 for <[e-mail]>; Thu, 5 Sep 2002 21:12:38 +0530
Message-ID: <00e201c254f2$f1e23db0$8502a8c0@hellosoftdomain>
From: "Vijay Raj" <[e-mail]>
To: <[e-mail]>
Subject: Query
Date: Thu, 5 Sep 2002 21:13:07 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01C25521.08168310"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00DF_01C25521.08168310
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
         Can anyone suggest me where to get the SMIME reference code

Regards
 Vijay

------=_NextPart_000_00DF_01C25521.08168310
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Can anyone suggest me where&nbsp;to get the SMIME reference =
code</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;Vijay</FONT></DIV></BODY></HTML>

------=_NextPart_000_00DF_01C25521.08168310--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83G7Eg14084 for ietf-smime-bks; Tue, 3 Sep 2002 09:07:14 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g83G7C214078 for <[e-mail]>; Tue, 3 Sep 2002 09:07:12 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Sep 2002 16:07:14 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA07366; Tue, 3 Sep 2002 12:07:08 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g83G4oh20376; Tue, 3 Sep 2002 12:04:50 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVPHDL>; Tue, 3 Sep 2002 12:07:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVPHDB; Tue, 3 Sep 2002 12:06:58 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Capel <[e-mail]>
Cc: [e-mail], [e-mail], "'Peter Gutmann'" <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 03 Sep 2002 10:54:59 -0400
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:     CompressedData
In-Reply-To: <001901c25353$3b612b50$01b5a8c0@tony>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony:

I think that vendors should be able to include a default in their 
products.  I do not think that we should make installation of the package 
ask questions that the naive user will be unable to understand.

Russ

At 10:07 AM 9/3/2002 -0400, Tony Capel wrote:
>Russ:
>
> >
> > On the receive side, we say that the S/MIME agent must be capable of
> > handling either order.
> >
> > On the sending side, we say that the S/MIME agent can include a
>default
> > method for handling this (either way), and they may optionally provide
>a
> > setting for the user to change the ordering.
> >
> > Russ
> >
>
>yes,
>
>With respect to the sending side issue, I guess my concern was that
>providing the implementer/vendor with a whole bunch of pros and cons may
>not be helpful, since IF they are developing a general purpose messaging
>system they will not know enough about its future use to decide.
>Rather, it would be more helpful just to say that the order must be
>capable of being set by the end user. In fact, for those end users who
>care, it will likely be set by organizational signing policy (e.g. bound
>to the profile of the desktop or certificate).  End user organizational
>security experts will hopefully decide, and although they may use the
>s/mime standard for input, I would hope they would refer to more
>specific documents to make their decision (e.g. ETSI signing
>directives). Similarly for implementers of specific-purpose messaging,
>they should have access to additional requirements documentation to
>allow them to decide.  So I think we should keep this decision "out of
>scope" for s/mime, since it is not an interoperability issue but rather
>an organizational policy issue reaching beyond s/mime (impacting more
>than just the order of signing and compression).
>
>On the other hand, what about the 90+% of users who don't care?  Should
>we (or the vendor) suggest a default value, or should the
>implementer/vendor "force" the end user to decide during installation,
>the first time or every time it is used?  I suggest we identify the two
>cases where the order of compression is fixed for technical reasons
>(compress before encryption and compress before sign if using non fully
>reversible compression), then say all other cases should be set by the
>end user but the default should be such-and-such since that will be
>least wrong most often ....  But if we are not comfortable suggesting a
>default, we could leave it to the vendor to decide the default (I'm not
>sure vendors will thank us for that).
>
>By all means put the pros and cons in.  But we should say that in those
>cases where it is important, it is the end user who must decide based on
>their own specific requirements. This implies that the end user MUST be
>able to change it since there appears to be valid reasons for either
>order.  The pros and cons could be used to support the suggested default
>value (if provided).
>
>tony


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83E77x04478 for ietf-smime-bks; Tue, 3 Sep 2002 07:07:07 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83E76204473 for <[e-mail]>; Tue, 3 Sep 2002 07:07:06 -0700 (PDT)
Received: from mail1.magma.ca (mail1.magma.ca [206.191.0.252]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g83E75lJ014891; Tue, 3 Sep 2002 10:07:05 -0400 (EDT)
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail1.magma.ca (Magma's Mail Server) with ESMTP id g83E6pJW009173; Tue, 3 Sep 2002 10:07:04 -0400 (EDT)
From: "Tony Capel" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:     CompressedData
Date: Tue, 3 Sep 2002 10:07:18 -0400
Message-ID: <001901c25353$3b612b50$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

> 
> On the receive side, we say that the S/MIME agent must be capable of
> handling either order.
> 
> On the sending side, we say that the S/MIME agent can include a
default
> method for handling this (either way), and they may optionally provide
a
> setting for the user to change the ordering.
> 
> Russ
> 

yes,

With respect to the sending side issue, I guess my concern was that
providing the implementer/vendor with a whole bunch of pros and cons may
not be helpful, since IF they are developing a general purpose messaging
system they will not know enough about its future use to decide.
Rather, it would be more helpful just to say that the order must be
capable of being set by the end user. In fact, for those end users who
care, it will likely be set by organizational signing policy (e.g. bound
to the profile of the desktop or certificate).  End user organizational
security experts will hopefully decide, and although they may use the
s/mime standard for input, I would hope they would refer to more
specific documents to make their decision (e.g. ETSI signing
directives). Similarly for implementers of specific-purpose messaging,
they should have access to additional requirements documentation to
allow them to decide.  So I think we should keep this decision "out of
scope" for s/mime, since it is not an interoperability issue but rather
an organizational policy issue reaching beyond s/mime (impacting more
than just the order of signing and compression).

On the other hand, what about the 90+% of users who don't care?  Should
we (or the vendor) suggest a default value, or should the
implementer/vendor "force" the end user to decide during installation,
the first time or every time it is used?  I suggest we identify the two
cases where the order of compression is fixed for technical reasons
(compress before encryption and compress before sign if using non fully
reversible compression), then say all other cases should be set by the
end user but the default should be such-and-such since that will be
least wrong most often ....  But if we are not comfortable suggesting a
default, we could leave it to the vendor to decide the default (I'm not
sure vendors will thank us for that).

By all means put the pros and cons in.  But we should say that in those
cases where it is important, it is the end user who must decide based on
their own specific requirements. This implies that the end user MUST be
able to change it since there appears to be valid reasons for either
order.  The pros and cons could be used to support the suggested default
value (if provided).

tony