Subject: ASN.1 Usage In S/MIME

From: "Phil Smiley" <[email-masked]>
Date: Sat, 28 Sep 2002 17:45:57 -0500

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

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 30 Sep 2002 09:47:04 -0400

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.
>

From: "Housley, Russ" <[email-masked]>
To: Phil Smiley <[email-masked]>
Cc: [email-masked]
Date: Mon, 30 Sep 2002 09:47:04 -0400
Subject: Re: ASN.1 Usage In S/MIME
Sender: [email-masked]

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.
>

Date: Sun, 29 Sep 2002 17:25:44 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  ASN.1 Usage In S/MIME
Sender: [email-masked]

"Phil Smiley" <[email-masked]> 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.

From: "Phil Smiley" <[email-masked]>
To: <[email-masked]>
Subject: ASN.1 Usage In S/MIME
Date: Sat, 28 Sep 2002 17:45:57 -0500
Sender: [email-masked]

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.

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--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-examples-08.txt
Date: Thu, 26 Sep 2002 08:35:01 -0400
Sender: [email-masked]

--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 <[email-masked]> 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 <[email-masked]> 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: X/MIME Anybody?
Date: Mon, 23 Sep 2002 11:42:06 +0200
Sender: [email-masked]

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

Anders

Date: Fri, 20 Sep 2002 09:51:08 -0400
To: [email-masked], [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: PKCS #1 v2.1 Internet-Draft
Sender: [email-masked]

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

Date: Wed, 18 Sep 2002 11:17:49 -0700
From: Himanshu Chatterjee <[email-masked]>
Organization: Server Technologies
CC: Steve Hanna <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

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" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> 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 [email-masked] is
> > actually the same mailbox as [email-masked]. 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.
> >

Date: Tue, 17 Sep 2002 16:27:58 -0700 (PDT)
From: [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
To: [email-masked]
Cc: Steve Hanna <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> 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

Date: Tue, 17 Sep 2002 15:36:59 -0700
From: [email-masked] (Bill Burns)
To: Steve Hanna <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

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 [email-masked] is
>actually the same mailbox as [email-masked]. 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

Date: Tue, 17 Sep 2002 17:23:52 -0400
From: Steve Hanna <[email-masked]>
To: [email-masked], [email-masked]
Subject: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

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 [email-masked] is
actually the same mailbox as [email-masked]. 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.

Date: Fri, 13 Sep 2002 20:50:01 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: Multipart non-clearsigned messages possible?
To: Elanor Foley <[email-masked]>
Cc: [email-masked]
Organization: KDE
Sender: [email-masked]

--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

--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)--

content-class: urn:content-classes:message
Subject: RE: Query
Date: Thu, 12 Sep 2002 08:12:40 -0400
From: "Nicholas, Richard" <[email-masked]>
To: "Vijay Raj" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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
[email-masked]
(301) 939-2722

From: "Housley, Russ" <[email-masked]>
To: Vijay Raj <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Sep 2002 20:20:17 -0400
Subject: Re: Query
Sender: [email-masked]

I suggest you contact John Pawling ([email-masked]).

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

From: "Housley, Russ" <[email-masked]>
To: Elanor Foley <[email-masked]>
Cc: [email-masked]
Date: Tue, 10 Sep 2002 18:58:58 -0400
Subject: Re: Multipart non-clearsigned messages possible?
Sender: [email-masked]

<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>

From: Elanor Foley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Multipart non-clearsigned messages possible?
Date: Mon, 9 Sep 2002 11:40:15 +0100 
Sender: [email-masked]

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--

To: IETF-Announce: ;
Subject: RFC 3370 on Cryptographic Message Syntax (CMS) Algorithms
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 05 Sep 2002 09:53:19 -0700
Sender: [email-masked]

--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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3369 on Cryptographic Message Syntax (CMS)
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 05 Sep 2002 09:51:09 -0700
Sender: [email-masked]

--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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

From: "Vijay Raj" <[email-masked]>
To: <[email-masked]>
Subject: Query
Date: Thu, 5 Sep 2002 21:13:07 +0530
Sender: [email-masked]

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--

From: "Housley, Russ" <[email-masked]>
To: Tony Capel <[email-masked]>
Cc: [email-masked], [email-masked], "'Peter Gutmann'" <[email-masked]>, [email-masked]
Date: Tue, 03 Sep 2002 10:54:59 -0400
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:     CompressedData
Sender: [email-masked]

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

From: "Tony Capel" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:     CompressedData
Date: Tue, 3 Sep 2002 10:07:18 -0400
Importance: Normal
Sender: [email-masked]

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