Re: Comments on draft-ietf-smime-compression-00.txt

[Sean Turner <[e-mail]>]

I agree with Jim.  Let's do it.

spt

Jim Schaad wrote:

> My personal opinion is that we have given the MIME people a lot of time to
> work on this issue.  They have not gotten anyplace that I am aware of so I
> think that we need to do it.  If we end up with two ways of doing this then
> the S/MIME draft could always say what is to be used for that application.
>
> jim
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Wednesday, March 29, 2000 3:15 PM
> To: [e-mail]
> Subject: Comments on draft-ietf-smime-compression-00.txt
>
> Does anyone have any further thoughts on compression as a CMS content type
> vs a MIME type?  I think this was more or less beaten to death (and
> beyond :-) the last time it came up, but if anyone has any further thoughts
> please post them.
>
> (The password issues are being worked on offline, I'll post an update in a
>  day or two).
>
> Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id XAA19854 for ietf-smime-bks; Thu, 30 Mar 2000 23:45:21 -0800 (PST)
Received: from atlas.arc.nasa.gov (atlas-ops.arc.nasa.gov [198.123.8.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19848 for <[e-mail]>; Thu, 30 Mar 2000 23:45:20 -0800 (PST)
Received: from ieca.com (1cust40.tnt2.cbr1.da.uu.net [210.84.115.40]) by atlas.arc.nasa.gov (8.8.5/8.7.3/arc) with ESMTP id XAA01835; Thu, 30 Mar 2000 23:47:34 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 31 Mar 2000 02:47:40 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Jim Schaad <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-smime-compression-00.txt
References: <[e-mail]>
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>

I agree with Jim.  Let's do it.

spt

Jim Schaad wrote:

> My personal opinion is that we have given the MIME people a lot of time to
> work on this issue.  They have not gotten anyplace that I am aware of so I
> think that we need to do it.  If we end up with two ways of doing this then
> the S/MIME draft could always say what is to be used for that application.
>
> jim
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Wednesday, March 29, 2000 3:15 PM
> To: [e-mail]
> Subject: Comments on draft-ietf-smime-compression-00.txt
>
> Does anyone have any further thoughts on compression as a CMS content type
> vs a MIME type?  I think this was more or less beaten to death (and
> beyond :-) the last time it came up, but if anyone has any further thoughts
> please post them.
>
> (The password issues are being worked on offline, I'll post an update in a
>  day or two).
>
> Peter.


Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00524 for ietf-smime-bks; Thu, 30 Mar 2000 16:34:34 -0800 (PST)
Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00516 for <[e-mail]>; Thu, 30 Mar 2000 16:34:31 -0800 (PST)
Message-Id: <[e-mail]>
Date: Thu, 30 Mar 2000 06:54:16 -0500
To: "Jim Schaad" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on the RSAES-OAEP draft
Cc: "Ietf-Smime" <[e-mail]>
In-Reply-To: <[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>

Jim:

1. Agree.

2. I cut-and-pasted it from RFC 2630, the place were I made the original 
mistake.

Thanks,
   Russ


At 01:06 PM 03/29/2000 +0930, Jim Schaad wrote:
>1.  Given that the question has been raised on at least one IETF mailing
>list, it might be advisable to state that the public key algorithm for rsa
>in a certificate is the same for v1.5 and v2.0.
>
>2.  You have consistantly gotten the RFC number for the v2.0 draft
>incorrect.  It is 2437 not 2347.
>
>
>jim



Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00127 for ietf-smime-bks; Thu, 30 Mar 2000 16:13:48 -0800 (PST)
Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00120 for <[e-mail]>; Thu, 30 Mar 2000 16:13:43 -0800 (PST)
Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id JAA13779 return <[e-mail]>; Fri, 31 Mar 2000 09:46:14 +0930 (CST)
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "Ietf-Smime" <[e-mail]>
Subject: RE: Comments on SecLabel draft
Date: Fri, 31 Mar 2000 09:45:47 +0930
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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>

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Jim Schaad
Sent: Wednesday, March 29, 2000 6:48 AM
To: "[e-mail];weston.nicolls"@ey.com;;;;
Subject: Comments on SecLabel draft


SecLabel

1.  Section 1 P2 - Security labels cannot be bound to an encrypted body,
only
to a signed message.

2.  Please give more text explaining the difference between rank and role
based
security.  From the current description they look like the same to me.

3.  The Amoco policy description is not clear.  From the text I assumed that
the confidentiality and integrity were orthogonal axis for make decisions
(thus
leading to 9 items).  Based on the conversation with you this is not true as
the policy is choose one of the axis and then the point on the axis.  The
text
should be clarified as to which is correct.

4. Typo - Section 1.2 last para - "while he outer signature" should be
"while
the".

5.  Section 2.2.1.3 -- I don't think that one should provide a syntax for
the
privacy marks.  However giving a couple of the privacy marks or guidelines
from
the policy on writting them might be useful.  Given that a privacy mark is a
UTF8 string in the syntax, no addtional ASN syntax is really possible.

6.  You say that categories are used informally, however without knowning
how
they would be used or specified I cannot even hope to offer syntax
suggestions.
 Given that they are informal why would they not be marked as privacy
labels.
 If they are categories then I would expect the policy module to do
enforcement
thus being informal would cause some difficulties.

7.  I suggest that you name Clearance in the ASN sections to be XxxxSection.
and the same for the other top level items.
http://www.nwlink.com



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23163 for ietf-smime-bks; Thu, 30 Mar 2000 09:20:21 -0800 (PST)
Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23158 for <[e-mail]>; Thu, 30 Mar 2000 09:20:19 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA18941; Thu, 30 Mar 2000 09:19:46 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <H1VZF18G>; Thu, 30 Mar 2000 09:18:58 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Jim Schaad'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-smime-compression-00.txt
Date: Thu, 30 Mar 2000 09:18:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0036_01BF9A42.458A3DF0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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_0036_01BF9A42.458A3DF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I think that the real issue is getting a compression algorithm out
there, any algorithm will do IMHO.

Implementing two sets of switching logic to turn on the compression
is not going to be a killer. In fact I think it is likely to be the
best solution.

Not supporting compression in the base web specs was the biggest 
mistake we made. We could have made 14K modems look like 28.8 modems 
if the early browsers had linked to gnuzip.


The piece that is currently missing is the means of advertising the
capabilities of the client. The biggest problem with messaging
is that the 1% of users with ASCII based clients stop the rest
of the email population using features like MIME, HTML, S/MIME
etc.

I can see that we might have problems if we were using a framework
like RDF to address this issue and the mechanism did not account
for the fact that clients might be able to do compressin in S/MIME 
but not in MIME (or vice versa).


Perhaps the real solution to this problem is to approach it
from another direction entirely. Rather than the RDF piecemeal
description of supported features maybe we should define client
profiles specifying feature sets that make sense. Then we could
distribute client capability info with a single certificate 
attribute.


		Phill

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Thursday, March 30, 2000 1:57 AM
To: [e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-smime-compression-00.txt


My personal opinion is that we have given the MIME people a lot of time
to
work on this issue.  They have not gotten anyplace that I am aware of so
I
think that we need to do it.  If we end up with two ways of doing this
then
the S/MIME draft could always say what is to be used for that
application.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Gutmann
Sent: Wednesday, March 29, 2000 3:15 PM
To: [e-mail]
Subject: Comments on draft-ietf-smime-compression-00.txt


Does anyone have any further thoughts on compression as a CMS content
type
vs a MIME type?  I think this was more or less beaten to death (and
beyond :-) the last time it came up, but if anyone has any further
thoughts
please post them.

(The password issues are being worked on offline, I'll post an update in
a
 day or two).

Peter.


------=_NextPart_000_0036_01BF9A42.458A3DF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDMzMDE3MjAwMVowIwYJKoZI
hvcNAQkEMRYEFNtrg7xlSFOO+5ET2XW+udhAHWytMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGArMO1lXHcf2Zuiwq902kkZDe2efqSt/hWy8y30z3+GuP2Kj0HPhmfPjwREWVttTOJ
jc+6tO4NxVQoldB4ftd7ItnM6JxKSu8JpWU3gkC7YkmwTQ13p0p4xRJIYx4igGCz9x/0Tr+kO3v3
N82/G0/3ce9qBHNkP3yqv8msK5F/xycAAAAAAAA=

------=_NextPart_000_0036_01BF9A42.458A3DF0--



Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28437 for ietf-smime-bks; Wed, 29 Mar 2000 22:55:39 -0800 (PST)
Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28432 for <[e-mail]>; Wed, 29 Mar 2000 22:55:36 -0800 (PST)
Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id QAA10863 return <[e-mail]>; Thu, 30 Mar 2000 16:27:22 +0930 (CST)
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-compression-00.txt
Date: Thu, 30 Mar 2000 16:26:54 +0930
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-reply-to: <[e-mail]>
Importance: Normal
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>

My personal opinion is that we have given the MIME people a lot of time to
work on this issue.  They have not gotten anyplace that I am aware of so I
think that we need to do it.  If we end up with two ways of doing this then
the S/MIME draft could always say what is to be used for that application.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Gutmann
Sent: Wednesday, March 29, 2000 3:15 PM
To: [e-mail]
Subject: Comments on draft-ietf-smime-compression-00.txt


Does anyone have any further thoughts on compression as a CMS content type
vs a MIME type?  I think this was more or less beaten to death (and
beyond :-) the last time it came up, but if anyone has any further thoughts
please post them.

(The password issues are being worked on offline, I'll post an update in a
 day or two).

Peter.




Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00524 for ietf-smime-bks; Wed, 29 Mar 2000 07:53:54 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00520 for <[e-mail]>; Wed, 29 Mar 2000 07:53:51 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA09426; Thu, 30 Mar 2000 03:56:15 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95434537508482>; Thu, 30 Mar 2000 03:56:15 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Compressed Data Content Type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 30 Mar 2000 03:56:15 (NZST)
Message-ID: <[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>

Maxim Masiutin <[e-mail]> writes:

>There is "PasswordRecipientInfo" defined in "Appendix A: ASN.1 Module" of 
>ietf-smime-compression-00.txt
>
>There are no references to PasswordRecipientInfo. How should we handle it?

By replacing it with "CompressedDataContent" :-).  I copied the OID across
from another draft and the text came with it.  Also it's listed as (n+1) 
(equivalent to the '?' or 'TBA' from other CMS drafts) where n currently 
appears to be 6 (id-mod-ets-eSignature-97), does anyone have any objections 
to id-mod-compression being 7?  In addition it looks like the listed value 
for id-ct-compressedData has been overtaken by newer drafts, since the 
highest one listed is id-ct-contentInfo(6) are there any problems with 
id-ct-compressedData being 7 as well?

(Before anyone points this out, I need to update the [CMS] reference as well,
 I know... draft-00 goes back awhile).

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA27516 for ietf-smime-bks; Wed, 29 Mar 2000 05:15:12 -0800 (PST)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27512 for <[e-mail]>; Wed, 29 Mar 2000 05:15:11 -0800 (PST)
Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id FAA24625; Wed, 29 Mar 2000 05:17:38 -0800 (PST)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: [e-mail];[e-mail];;;
Date: Wed, 29 Mar 2000 05:17:38 +0800
Subject: Comments on SecLabel draft
Message-id: <[e-mail]>
X-User-Info: 208.212.202.133
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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>

SecLabel

1.  Section 1 P2 - Security labels cannot be bound to an encrypted body, only
to a signed message.

2.  Please give more text explaining the difference between rank and role based
security.  From the current description they look like the same to me.

3.  The Amoco policy description is not clear.  From the text I assumed that
the confidentiality and integrity were orthogonal axis for make decisions (thus
leading to 9 items).  Based on the conversation with you this is not true as
the policy is choose one of the axis and then the point on the axis.  The text
should be clarified as to which is correct.

4. Typo - Section 1.2 last para - "while he outer signature" should be "while
the".

5.  Section 2.2.1.3 -- I don't think that one should provide a syntax for the
privacy marks.  However giving a couple of the privacy marks or guidelines from
the policy on writting them might be useful.  Given that a privacy mark is a
UTF8 string in the syntax, no addtional ASN syntax is really possible.

6.  You say that categories are used informally, however without knowning how
they would be used or specified I cannot even hope to offer syntax suggestions.
 Given that they are informal why would they not be marked as privacy labels.
 If they are categories then I would expect the policy module to do enforcement
thus being informal would cause some difficulties.

7.  I suggest that you name Clearance in the ASN sections to be XxxxSection.
and the same for the other top level items.
http://www.nwlink.com


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA26315 for ietf-smime-bks; Wed, 29 Mar 2000 04:19:27 -0800 (PST)
Received: from gate.ritlabs.com (IDENT:[e-mail] [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26311 for <[e-mail]>; Wed, 29 Mar 2000 04:19:22 -0800 (PST)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id PAA23567 for <[e-mail]>; Wed, 29 Mar 2000 15:24:11 +0300
Date: Wed, 29 Mar 2000 15:21:25 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/9)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Peter Gutmann <[e-mail]>
Subject: Compressed Data Content Type for S/MIME
Mime-Version: 1.0
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>

Hello Peter!

  There is "PasswordRecipientInfo" defined in "Appendix A: ASN.1
  Module" of ietf-smime-compression-00.txt

  There are no references to PasswordRecipientInfo. How should we
  handle it?


-- 
Max Masyutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23578 for ietf-smime-bks; Tue, 28 Mar 2000 19:34:36 -0800 (PST)
Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23566 for <[e-mail]>; Tue, 28 Mar 2000 19:34:33 -0800 (PST)
Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id NAA06036 return <[e-mail]>; Wed, 29 Mar 2000 13:06:43 +0930 (CST)
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>
Subject: Comments on the RSAES-OAEP draft
Date: Wed, 29 Mar 2000 13:06:15 +0930
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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>

1.  Given that the question has been raised on at least one IETF mailing
list, it might be advisable to state that the public key algorithm for rsa
in a certificate is the same for v1.5 and v2.0.

2.  You have consistantly gotten the RFC number for the v2.0 draft
incorrect.  It is 2437 not 2347.


jim



Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21828 for ietf-smime-bks; Tue, 28 Mar 2000 19:13:02 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21824 for <[e-mail]>; Tue, 28 Mar 2000 19:12:59 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id PAA15104 for <[e-mail]>; Wed, 29 Mar 2000 15:15:08 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95429970802782>; Wed, 29 Mar 2000 15:15:08 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Comments on draft-ietf-smime-compression-00.txt
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 29 Mar 2000 15:15:08 (NZST)
Message-ID: <[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>

Does anyone have any further thoughts on compression as a CMS content type
vs a MIME type?  I think this was more or less beaten to death (and 
beyond :-) the last time it came up, but if anyone has any further thoughts
please post them.

(The password issues are being worked on offline, I'll post an update in a 
 day or two).

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id TAA28083 for ietf-smime-bks; Mon, 27 Mar 2000 19:06:49 -0800 (PST)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA28079 for <[e-mail]>; Mon, 27 Mar 2000 19:06:48 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJLAC1>; Mon, 27 Mar 2000 22:08:40 -0500
Message-ID: <[e-mail]>
From: =?UTF-8?B?UGF3bGluZywgSm9obg==?= <[e-mail]>
To: =?UTF-8?B?J0ppbSBTY2hhYWQgJw==?= <[e-mail]>, =?UTF-8?B?J0NhbWVyb24gU3RpbGxpb24gJw==?= <[e-mail]>, =?UTF-8?B?J2lldGYtc21pbWVAaW1jLm9yZyAn?= <[e-mail]>
Cc: =?UTF-8?B?J0JyeWFuIFN0YWF0cyAn?= <[e-mail]>
Subject: =?UTF-8?B?UkU6IEVTUyA6IFNlY3VyZSBSZWNlaXB0IGVuY29kaW5nIHdpdGhp?= =?UTF-8?B?biBFbmNhcHN1bGF0ZWRDb250ZW50SW5mbw==?=
Date: Mon, 27 Mar 2000 22:08:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Content-Type: text/plain; charset="UTF-8"
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>

Jim,

I agree with all of your statements except for bullet #3.  You stated that
the OCTET wrapping can be omitted if an ESS receipt content-type is
encapsulated within a PKCS#7 signedData.  This would cause severe
interoperability problems with an RFC 2630/RFC 2634 (a.k.a. CMS/ESS)
implementation such as the S/MIME Freeware Library.    

RFC 2630 (CMS) defines EncapsulatedContentInfo as follows:
 EncapsulatedContentInfo ::= SEQUENCE {
      eContentType ContentType,
      eContent [0] EXPLICIT OCTET STRING OPTIONAL }

If the eContent field is present, then the OCTET STRING tag and length
octets must be present in the encoding of the signedData.
 
RFC 2634 (ESS), Section 2.4, bullet 9 states: "The ASN.1 DER encoded
Receipt content MUST be directly encoded within the signedData
encapContentInfo eContent OCTET STRING defined in [CMS]."

Notice the text "defined in [CMS]".  A valid encoding of an ESS signed
receipt MUST contain the signedData encapContentInfo eContent OCTET STRING
tag and length octets.  If the eContent OCTET STRING tag and length octets
are omitted (as you suggest in your message), then a CMS/ESS implementation
cannot decode the message.

There is no text in ESS that addresses the inclusion of a receipt content in
a PKCS #7 signedData.  If there was such text, it would need to state that
the ASN.1 DER encoded Receipt content MUST be directly encoded within an
OCTET STRING within the PKCS #7 signedData contentInfo content
defined in PKCS #7.  This is the only way (without changing the CMS
encapContentInfo eContent syntax) that signed receipt interoperability can
be achieved between CMS/ESS and PKCS #7/ESS implementations.  

If you believe that there will be PKCS #7/ESS implementations that are
sending signed receipts, then the aforementioned text needs to be included
in RFC 2634.

Thank you for your feedback,
-John Pawling


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA28531 for ietf-smime-bks; Mon, 27 Mar 2000 02:50:33 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28526 for <[e-mail]>; Mon, 27 Mar 2000 02:50:32 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dhcp-193-54.ietf.connect.com.au [169.208.193.54]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id CAA21399; Mon, 27 Mar 2000 02:51:38 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 27 Mar 2000 05:32:42 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: LAST CALL:draft-ietf-smime-password-02.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
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>

Peter:

One of the first decisions that the S/MIME working group made was to use 
1988 ASN.1.  This decision was made for several reasons, including the 
availability of compilers.  So, if you want this to move forward as part of 
the S/MIME Standards Track document series, then you will have to reverse 
port the ASN.1.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id XAA23685 for ietf-smime-bks; Sun, 26 Mar 2000 23:31:57 -0800 (PST)
Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23678 for <[e-mail]>; Sun, 26 Mar 2000 23:31:54 -0800 (PST)
Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id RAA32662 return <[e-mail]>; Mon, 27 Mar 2000 17:04:04 +0930 (CST)
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: LAST CALL:draft-ietf-smime-password-02.txt
Date: Mon, 27 Mar 2000 17:03:35 +0930
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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>

Here are the set of last call comments that I have for this draft.

1.  You still have a reference to PKCS #5 v2 in the document. (PKCS#5 v2 is
not an information or other RFC.)  If you want this document to be on
standards track rather than informational then this issue needs to be
resolved.

2.  Section 2.1.  The S/MIME working group is using 88 ASN syntax.  The
syntax in this section is not.  Please correct.

<previous response from peter>
PKCS #5 uses current ASN.1 syntax and not the 1988 version, the ASN.1 used
is taken straight from the standard.

3.  Section 2.1  Why is there ASN here that does not actually provide any
useful information.  What are the parameters.  What is the OID associated
with this set of parameters.  This is an issue for both the fact that PKCS#5
is not an RFC and the ASN.1 is not 1988.

<previous response from peter>
It's copied from PKCS #5 for completeness, I didn't want to include the
whole thing verbatim but did want to include enough information that readers
wouldn't have to keep flipping back and forth between the two.

4.  Section 2.3.1 - I will raise the issue of the fact that the key wrap
algorithm is not the same as CMS even though the CMS version is a MUST
implement.  At a minimum you should make the CMS version the MUST and the
version you have in your document an optional version to have.

5.  Based on a past email with Carlisle Adams, I think that changing title
to "Password-based Encryption for CMS" is a reasonable thing to do.

6.  Why does a version with keyDerivation optional exist in this draft?  It
appears to me that this is exactly the same thing as is done by
kekRecipientInfo (i.e. an existing KEK key is used to wrap a CEK key).  I
would not be in favor of having two different methods for doing this.

7.  I don't understand why onlyi the first 3 bytes of the CEK are used for
the checksum.  What is the problem with using the first 3 bytes of a SHA1
hash.  I don't think the performance difference is going to be significant.

8.  The test vectors should be modified to use one of the standard CMS
algorithms if they are going to be present in the draft.  Blowfish is not an
algorithm that one should expect most CMS developers to have implemented.
RC2 and 3DES are.

jim



Received: by ns.secondary.com (8.9.3/8.9.3) id WAA23065 for ietf-smime-bks; Sun, 26 Mar 2000 22:59:27 -0800 (PST)
Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23060 for <[e-mail]>; Sun, 26 Mar 2000 22:59:24 -0800 (PST)
Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id QAA32577 return <[e-mail]>; Mon, 27 Mar 2000 16:31:35 +0930 (CST)
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
Subject: RE: LAST CALL: draft-ietf-smime-cast-128-01.txt
Date: Mon, 27 Mar 2000 16:31:06 +0930
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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 have the following comments on the draft at this stage.  I am sorry for
being late, but I have been on holidays.

1.  In section 3 paragraph 1 -- The size needs to be required for an
SMimeCapablity and cannot be MAY.  We do binary comparisions to see if the
algorithms are the same so there can be no MAY fields.

2.  In section 3 --  Again I ask that you include the actual list of bytes
that are to be used for the SMimeCaps fields.  For an example of what I am
looking for you can look at section 7 of CMSKEA.  Due to the fact that a
binary comparision is being done, it is best to allow for no errors in the
encoding of this field.

Jim Schaad



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA09139 for ietf-smime-bks; Sun, 26 Mar 2000 16:24:21 -0800 (PST)
Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09135 for <[e-mail]>; Sun, 26 Mar 2000 16:24:17 -0800 (PST)
Received: from dhcp-32-60.ietf.connect.com.au [169.208.32.60] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id JAA31448 return <[e-mail]>; Mon, 27 Mar 2000 09:56:11 +0930 (CST)
From: "Jim Schaad" <[e-mail]>
To: "Cameron Stillion" <[e-mail]>, <[e-mail]>
Cc: "Bryan Staats" <[e-mail]>
Subject: RE: ESS : Secure Receipt encoding within EncapsulatedContentInfo
Date: Mon, 27 Mar 2000 09:55:42 +0930
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01BF97D2.9CF82E20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <E46F2E74BFC4CF119A8B00805FCCAB2708DC73E2@RENCHOW>
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
X-MS-TNEF-Correlator: <[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>

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BF97D2.9CF82E20
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Just to be a little more clare abouit this.  My response would be as
follows:

1.  It is stated that the reciept must be DER encoded.
2.  The directly statement is made with respect to the lack of a MIME =
layer
being inserted between the receipt content and the surrounding =
SignedData
ASN construct (i.e. the MIME layer is omitted unlike what is done in
wrapping a signed message in an encrypted message).
3.  The OCTET wrapping or lack of is addressed by either PKCS#7 or CMS
drafts.  It is present for CMS and omitted for PKCS#7.

jim

-----Original Message-----
From: [e-mail] =
[mailto:[e-mail]]On
Behalf Of Cameron Stillion
Sent: Friday, March 10, 2000 11:45 AM
To: '[e-mail]'
Cc: '[e-mail]'; Bryan Staats
Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo


... and now for something completely different:
=20
According to the ESS RFC on page 16, step 9:
=20
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded =
within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].

Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
=20
The word "directly" seems to indicate that the former is the correct =
one.
Just tell me I'm not crazy.
=20
Cameron Stillion

------=_NextPart_000_0004_01BF97D2.9CF82E20
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IioAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHAwAbAAkANQAAAAEANAEB
A5AGAGgJAAApAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAIBMQAB
AAAARgAAAAAAAABMoh5f/LnPEZlLAAAAAAABBwAu/QEUBSTPEZkQAKoAbIDRAAAAvtAzAADkby50
v8TPEZqLAIBfzKsnAAAIzl1/AAAAAAMANgAAAAAAHgBwAAEAAAA9AAAARVNTIDogU2VjdXJlIFJl
Y2VpcHQgZW5jb2Rpbmcgd2l0aGluIEVuY2Fwc3VsYXRlZENvbnRlbnRJbmZvAAAAAAIBcQABAAAA
GwAAAAG/igJBXPhvcFf1zBHThDoAYLDsDf8DX0OOIAACAR0MAQAAABcAAABTTVRQOkpJTVNDSEBO
V0xJTksuQ09NAAALAAEOAAAAAEAABg4ACn+bgpe/AQIBCg4BAAAAGAAAAAAAAADGH5V+7uPTEZY8
AACGM1pkwoAAAAsAHw4BAAAAAgEJEAEAAABKBAAARgQAAOQGAABMWkZ1x40WzgMACgByY3BnMTI1
4jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMR
JfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSgR1cwVAdG8gYmWgIGEg
bGkCQGwdgPMEYBggIGMLYB5RAaAIYEsd0B0waAQALiAF0HkyIBggc3ACIBQQIHe5CGBsZB1jBCAC
EGwXsLh3czoKogqECoAxH5HWSQVABAAgHRBhDrAgwN8fUCNAH0EdgBggYwiQBTGGbR0CHXFERVIg
CfBTBaABAGQuIcQyH5FU+SPxZGkkIR3wH9AjIweAvwIwIuIAwAEAIHAd0Ggf4w8m8R0yI+ILYGNr
IG9CZh2RTUlNRSmhefcSgR1wC4BnIuAgQQAgI2H5HXB0dwnhI9YrEAUxBaDfAjAnsgBwI3IdgHMI
cANghnUtwCsiU2lnbgmAxkQjQB2gQVNOLSIdEIZyGtAFQChpLmUfkP8j4ipZIvEDcB3RI2EugB3A
7msgYSOiIvFkAiAdgAuA4SBwcmFwcCsiHaAAkMcvEh4gB5BzYWczowORWSVhcnkFMDToKSXVM8Em
VU9DVEVUM+gFsfcptiLxKDBkH/EUECDBH9AHKxAj4QXAUEtDUyPaNzjiQwXhOfBhAYAfgv0ixHAf
8SeyAhA7lC2yMgZvPWI7FCXVIcRqB3Ahyi31QQJPBRBnC4AHQAXQNSSrQQMhxEYDYTop8HcvIMxy
LQiQADAtczIQB4CWQADAAxAuB3BjLgWwbStAW0RyHUA6Q29Eel1STwOgQmUT4GwqEE85KhBDYQeA
A2ADoFN0/wMQHcACICHEBmACMENAQwB0aWQqsCwF0ArAE9AgPDEwSpAB0EtgSwAxOlQ0NRDATSHE
VEWgIJYnRilExSchxENjTKG8cGgqAARQAHBNdztHwFc2IAORSPBhI0BzSXV1zGJqJvFDQEVTBfBD
QO0GYGMIcB2AUizFJWMrIvsocjPBRSVwNBAuMAtgI1FzCFAtU0luAhAhyiHELttWcC2jbiGAPVNz
A3AUILdToStABaBtC1AUIGUnIX8mwAEgBJBJ4iHECuMKgEEeYwWhLqMpRVGSUkZDzynwA6AKsDVh
MTZKkB0QaSRgIDlZXDkmVS+hLo4xJRpSVy02TVVTOED/HXEmx17mU3Ut8y8IJWE0EB9UqSVQVKU3
9WCAUklOvkcmsAEQC4AjYTPBWzux+l0/S1NOwCCiZGcdcyUh7i1S5yoBLHk/WWVrAQWw/2c/aE9p
VwORZPstMgtxWpN/I/Fo72n/WcUmgiCACyAg2iImxiIjEAngbQQgHUH/C4AmwFQADrAjiD1hSJEi
4v8j4gWhJuJbsTCxHOVYgAMgcweAIrAnbVbhLRE0AHpeeSXVWcVIfyHTfXswAAAeAEIQAQAAADMA
AAA8RTQ2RjJFNzRCRkM0Q0YxMTlBOEIwMDgwNUZDQ0FCMjcwOERDNzNFMkBSRU5DSE9XPgAAAwAA
gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAABShQAA
J2oBAB4ABIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAAWACCAGAAAAAADA
AAAAAAAARgAAAAAGhQAAAAAAAAMABoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAHgAgg
BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALAAiACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA
AAMACYAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAA
GIUAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAA
AAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAADiF
AAABAAAAAQAAAAAAAAAeABCACCAGAAAAAADAAAAAAAAARgAAAACDhQAAAQAAABMAAAAyMDAyNDU5
MjMtMjYwMzIwMDAAAAsAFoAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAgH4DwEAAAAQAAAA
xh+Vfu7j0xGWPAAAhjNaZAIB+g8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQCAfsPAQAAAE0AAAAA
AAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABD
OlxtYWlsXGN1cnJlbnQucHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAA8TkRCQkpH
RE1NR0JQQkRFTkxFSUhHRUlOQ0FBQS5qaW1zY2hAbndsaW5rLmNvbT4AAAAAAwAGEHUgb7MDAAcQ
RgQAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABKVVNUVE9CRUFMSVRUTEVNT1JFQ0xBUkVB
Qk9VSVRUSElTTVlSRVNQT05TRVdPVUxEQkVBU0ZPTExPV1M6MUlUSVNTVEFURURUSEFUVEhFUkVD
SUVQVE1VU1RCRURFUkVOQ09EAAAAABpD

------=_NextPart_000_0004_01BF97D2.9CF82E20--



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA04882 for ietf-smime-bks; Sun, 26 Mar 2000 11:08:54 -0800 (PST)
Received: from mail.harrassowitz.de (intergw.harrassowitz.de [193.97.189.19]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA04878 for <[e-mail]>; Sun, 26 Mar 2000 11:08:51 -0800 (PST)
Message-Id: <[e-mail]>
Received: from cranston-ip-2-123.dynamic.ziplink.net by mail.harrassowitz.de with SMTP (AIX 4.1/UCB 5.64/GEN-1.2.0) via EUnet for mail.proper.com id AA17824; Sun, 26 Mar 2000 19:35:02 +0200
From: "Owen" <[e-mail]>
Subject: Get Ready For Some Mail That You Like
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Sun, 26 Mar 2000 14:37:15 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA04879
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>

Hi,

Perhaps this might be of interest to you.


HERE IS YOUR REQUESTED INFORMATION!:
 
Fellow entrepreneur:

Don't knock it until you at least read this.  

For the first time ever, I have received a piece of
email that actually delivered more than just empty promises!
 
5LIST!  = $$$$$ IN THE BANK!

Perhaps this might be of interest to you?

GET PAID $5 PER SIGNUP TO BUILD YOUR OWN MAIL LIST!
.......why do it for free??
(Example: you get 10
   they get 10ea.=100
  they get 10 ea.=1000
WOW!~Each sending $5 to you=WOW!)

If you need to make a few thousand dollars REALLY FAST, then please,
take a moment to read this simple program I am sharing with you.

You DO NOT have to send $5 to five people, buy their reports, or
recipes, or anything like that. Nor will you have to invest more
money later to get things going.
 
THIS IS THE FASTEST, EASIEST PROGRAM YOU WILL EVER DO.  
 
Complete it in one hour, and you will never forget the day you first
received it.

The following is a plan to benefit you and your future. $$$$$ BE
PREPARED TO GET EXCITED...YOU WON'T BE   DISAPPOINTED!!!

Read the following and you will agree this is a very exciting 
opportunity. Only invest a little bit of time, and your reward could
mean thousands of dollars! Good luck!
 
*********************************************************************
************ 
&ldquo;IT'S OUTRAGEOUS!!!  With two hours of work I have made over US
$11,000 In the last three weeks&hellip;..and my investment was just 
$5!!!  I LOVE IT!
Thank you 11,000 x's!&rdquo; -Julie M. St. Louis
*********************************************************************
*********** ARE YOU IN
NEED OF MONEY RIGHT NOW?  HOW DOES $10,000 IN TWO WEEKS SOUND?  Don't
laugh!  
Try this, for a change, while you wait for the others to start
working. 
One hour of work to get started and no mailing lists!
 
*********************************************************************
******
Esquire Marketing Newsletter Gift Club. This service is 100% 
legal (Refer to US Postal and Lottery Laws, Title18, Section 1302 and
1341, or Title 18, Section 3005 in the US code, also in the code of
federal regulations, Volume 16,  Sections 255 and 436, which state "a
product or service must be exchanged for
money received")
*********************************************************************
**********
Here's How It Works:  Unlike many other programs, this three level
program is more realistic  and much, much faster. Because it is so
easy, the response rate for this program is VERY HIGH AND VERY FAST,
and you will see results in two weeks or less!
 
Just in time for next month's bills! You only mail out 20 copies (not
200 or more as in other programs). You should also send them to
people who send you their programs, because they know these programs
work and they are already believers in the
system!

Besides, this program is MUCH, MUCH FASTER and has a HIGHER  RESPONSE
RATE! Even if you are already in a program, stay with it, but do
yourself a favor and DO THIS ONE as well.  

START RIGHT NOW!  It's simple and takes a very small investment.
It will pay off long before other letters even begin to trickle in!

$$$$$

Just give ONE person a $5 gift.  That's all!

$$$$$

Follow the simple instructions and in two weeks you will have US$10,0
00 in your bank account!  Because of the LOW INVESTMENT, SPEED, and
HIGH PROFIT POTENTIAL, this program has a VERY HIGH RESPONSE RATE!
Just one
(1) US $5 bill.  That's your investment!!!

*********************************************************************
**********
Follow These Simple Instructions:

1) On a blank sheet of paper write "Please add me to your mailing
list." Write your name and address clearly and  include your email
address for future mailings and courtesy follow ups.  
 
Fold it around a US $5 and send it to the FIRST name on the list (#1)
.  Only the first person on the list  gets your name and a
five dollar gift.

2) Retype only the list,  removing the FIRST (#1)  NAME FROM THE LIST
.  Move the other two names UP and ADD YOUR NAME   to the list in the
THIRD (#3) position.

3) Send out 20 copies of this letter.  NOTE: by sending this letter
via    EMAIL, The response time is much faster, and you
save the expenses of envelopes,stamps, and copying services

Consider this; MILLIONS of people "surf the Internet"everyday, all
day, all over the world! Fifty thousand new people get on the
Internet every month!  An excellent source of names are the people
who send you other programs and the names listed onthe letter they
send you.  
Your contact source is UNLIMITED!  It boggles my mind to think of all
the possibilities! 

Mail, or should I say Email, your letter TODAY!  It's so easy. One
hour of your time.  THAT'S IT!

To send your newsletter by Email:
1) Go to "edit" and "select all"
2) Go to "edit" and "copy"
3) Start (compose) a new Email message
4) Address your Email and Subject blocks
5) Go to "edit" and "paste".
After you have pasted this article to your new Email, 
delete the old header and footer (Subject, Date, To, From, Etc.)  
Now you can edit the names and addresses with ease. 
I recommend deleting the top name, adding your name and address to
the bottom of the list, then simply changing the numbers.

THERE'S NOTHING MORE TO DO.  
When your name reaches the first position in a few days, it will be
your turn to collect your gifts.  The gifts will be sent to you by
1,500 to 2,000 people like yourself, who are willing to invest US $5
and one hour to receive US $10,000 in cash. That's all!  

There will be a total of US$10,000 in US$5 bills in your mailbox in
two weeks. US$10,000 for one hour&rsquo;s work!  I think it's WORTH
IT, don't you?
 
GO AHEAD...TRY IT.  IT'S US$5!... EVEN IF YOU MAKE JUST 3 OR 4
THOUSAND,  WOULDN'T THAT BE
NICE?  IF YOU TRY IT, IT WILL PAY!

*********************************************************************
*********** 
TRUE STORY
Cindy Allen writes:  
&ldquo;I ran this gift summation four times last year. The first time
I received over $7,000 in cash in less than two weeks and
over $10,000 in cash in the next three times I ran it.  I can't begin
to tell you how great it feels Not to have to worry about
money anymore!  I thank God for the day I received this letter! It
has truly changed my life!  
 
Don't be afraid to make gifts to strangers, they'll come back to you
in ten-fold.  
 
So, let's keep it going and help each other out in these "tough and
uncertain times."

*********************************************************************
*********** 
CAN I DO IT AGAIN? OF COURSE YOU CAN
this plan is structured for everyone to send only 20 letters each. 
However, you are certainly not limited to 20. Mail out as many as you
can.  Every 20 letters you send has a return of $10,000
or more.   If you can mail forty, sixty, eighty, or whatever, 
 
GO FOR IT!  THE MORE YOU PUT INTO IT, 
THE MORE YOU GET OUT OF IT

Each time you run this program, just follow steps 1 thru 3 and
everyone on your gift list benefits! Simple enough? You bet it is!
Besides, there are no mailing lists to buy,(and wait for), and trips
to the printer or copier, and you can do it again and again,
with your regular groups or gifters, or start up a new group.
 
Why not?  It beats working!  

Each time you receive an MLM offer, Respond with this letter!  
Your name will climb to the number one position at dizzying rates
Follow the simple instructions, and above all, PLEASE PLAY FAIR.
That's the key to this program&rsquo;s success. Your name must run
the full gamut on the list to produce the end results.
Sneaking your name higher up on the list WILL NOT produce the results
as you think, 
and it only cheats the other people who have worked hard and have
earned the right to be there.  
 
So please, 
play by the rules and the $$$ will come to you!

*********************************************************************
***********
MAIL YOUR LETTERS OUT TODAY!

 $$$  
 Together we will prosper!  
 $$$ GOOD LUCK!!!


*********************************************************************
************
1.   Bonnie Mallalieu                                                
               
      MC Box 5179
      Clinton, MS 39058
 
2.   FWM Marketing
      1602 N Maryland Ave
       Plant City, Fl 33556

3.   Paul D. Gram
      16277 NW 20th St
      Pembroke Pines, Fl. 33028



*********************************************************************
********** 
Wishing you the best in all you do! You probably don't believe this
will work, but if you don't try it, you will never know. That's the
way I felt.  
Try it.  You won't be sorry. 
Paul Gram


For support and to Maximize your success Email me with "5list"in
subject heading along with a copy of your re-done list
*********************************************************************
************
IMPORTANT: This is a one and only email, if you do not join, if you
are not interested or even if you are interested, you will
not get any more email regarding this from me. It is up to you now.
*********************************************************************
*********** 
WISHING YOU THE BEST LIFE HAS TO OFFER!


*********************************************************************
***************
Please Remove at:
mailto:[e-mail]?subject=remove
*********************************************************************
***************





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA15606 for ietf-smime-bks; Thu, 23 Mar 2000 11:33:20 -0800 (PST)
Received: from inet-smtp3.oracle.com (inet-smtp3.us.oracle.com [205.227.43.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15602 for <[e-mail]>; Thu, 23 Mar 2000 11:33:19 -0800 (PST)
Received: from mailsun3.us.oracle.com (mailsun3.us.oracle.com [130.35.62.244]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id LAA28332; Thu, 23 Mar 2000 11:35:17 -0800 (PST)
Received:  from us.oracle.com by mailsun3.us.oracle.com with ESMTP (8.8.8+Sun/37.9) id LAA25741; Thu, 23 Mar 2000 11:35:17 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 23 Mar 2000 11:43:06 -0800
From: Guang Yee <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pawling, John" <[e-mail]>
CC: "'SMIME WG'" <[e-mail]>
Subject: Re: v1.5 SFL Freely Available to All!!
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------8B518FEC5C6CAE5D1E8289D6"
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.
--------------8B518FEC5C6CAE5D1E8289D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Is SFL v1.5 currently available on HP? If not, when will SFL v1.5 be ported to
HP?

Thanks,

Guang

"Pawling, John" wrote:

> All,
>
> J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
> delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and
> Application Programming Interface (API).  The SFL source code files are
> freely available to everyone from the Fortezza Developer's S/MIME Page
> <http://www.armadillo.huntsville.al.us/software/smime> (with no password
> control).  On 14 January 2000, the U.S. Department of Commerce, Bureau of
> Export Administration published a new regulation implementing an update to
> the U.S. Government's encryption export policy
> <http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the
> revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
> the downloading of the SFL source code is no longer password controlled.
>
> The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message
> Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications.
> It also implements portions of the RFC 2633 Message Specification and
> RFC 2632 Certificate Handling document.  When used in conjunction with
> the Crypto++ freeware library, the SFL implements the RFC 2631
> Diffie-Hellman (D-H) Key Agreement Method specification.  It has been
> successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating
> systems.  Further enhancements, ports and testing of the SFL are still in
> process.  Further releases of the SFL will be provided as significant
> capabilities are added.
>
> The SFL has been successfully used to sign, verify, encrypt and decrypt
> CMS/ESS
> objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
> 3DES)
> provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by
> the
> RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms
> provided by the Fortezza Crypto Card.  The SFL uses the VDA-enhanced SNACC
> v1.3
> ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL
> High-
> level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL);
>
> BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested);
> VDA-
> enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities;
>
> test drivers and test data.  All CTILs were tested as Dynamically Linked
> Libraries (DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
> were
> tested with the respective security libraries as shared objects using
> Solaris 2.7.
>
> The SFL has been successfully used to exchange signedData and envelopedData
> messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and
>
> Netscape Communicator 4.X S/MIME v2 products.  Signed messages have been
> exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products.
>
> The SFL has also been used to perform S/MIME v3 interoperability testing
> with
> Microsoft that exercised the majority of the features specified by RFCs
> 2630,
> 2631 and 2634.  This testing included the RSA, mandatory S/MIME V3 and
> Fortezza
> suites of algorithms.  We have also performed limited S/MIME v3 testing with
>
> Baltimore and Entrust.  We are also participating in the IETF S/MIME WG
> interoperability testing documented in the "Examples of S/MIME Messages"
> document.  We have used the SFL to successfully process all of the correct
> signedData and envelopedData messages included in the document.  We are
> continuing to set up test config files to use the SFL to test the other
> cases
> included in the document such as signed receipts.  We also plan to provide
> sample messages for inclusion in the document.
>
> The following enhancements are included in the v1.5 SFL release (compared
> with
> the v1.4 release):
>
> 1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly
> processed.
>
> 2) Fixed many memory leaks;
>
> 3) Full CounterSignature test suite (autohiAllSFLd.cfg);
>
> 4) CertificateBuilder utility generates private/public key pairs and
> certificates (there is a "README.txt" file in the root directory regarding
> this
> utility).
>
> 5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS
> #11
> crypto library, but this project provides a good template for PKCS #11).  We
>
> are still testing the PKCS #11 CTIL.
>
> 6) Developed new test code and configuration files to implement test cases;
> and
>
> 7) Performed regression testing to ensure that aforementioned enhancements
> did
> not break existing SFL functionality.
>
> We are still in the process of enhancing and testing the SFL.  Future
> releases
> will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL
> encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line
> utility; modify PKCS #12 code in test utilities to provide interoperable key
>
> storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode
> functions; add enhanced test routines; bug fixes; support for other crypto
> APIs
> (possible); and support for other operating systems.
>
> The SFL is developed to maximize portability to 32-bit operating
> systems.  In addition to testing on MS Windows and Solaris 2.7, we plan to
> port
> the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2
> (possibly), SCO 5.0 (possibly) and Macintosh (possibly).
>
> The following SFL files are available from the Fortezza Developer's S/MIME
> Page:
>
> 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API,
> Software Test Description, Implementers Guide, Overview Briefing and Public
> License.
>
> 2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler
> and
> Library source code compilable for Unix and MS Windows NT/95/98 that has
> been
> enhanced by VDA to implement the Distinguished Encoding Rules.  Project
> files
> and makefiles are included.  This file includes a sample test project
> demonstrating the use of the SNACC classes.
>
> 3) smimeR15.zip:  Zip file containing all SFL source code including:
> SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source
> code; project files.  This file also contains test driver source code,
> sample CMS/ESS test data and test X.509 Certificates.  This file also
> includes test utilities to create X.509 Certificates that each include
> a D-H, DSA or RSA public key.  SNACC release and debug libraries
> are compiled for MS Windows NT/95/98. MS Windows NT/95/98
> project files and Unix makefiles are included for the SNACC code and
> Crypto++.
>
> 4) smR15CTI.zip:  Source code for the following CTILs: Test (no crypto),
> Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11.  The Win95/98/NT projects are
>
> also included.  (NOTE: The Free (a.k.a. Crypto++) CTIL includes
> VDA-developed
> source code to use the RSA public key algorithm implemented within the
> external
> Crypto++ library.  As with all of the external crypto token libraries, the
> Crypto++ library is not distributed as part of the SFL source code.
> To use the Crypto++ library with the SFL, the application developer must
> independently obtain the Crypto++ library from the Crypto++ Web Page
> <http://www.eskimo.com/~weidai/cryptlib.html> and then compile it with
> the VDA-developed Crypto++ CTIL source code.  The RSA public key
> algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication
> System and Method".  Within the U.S., users of the RSA public key algorithm
> provided by the external Crypto++ library must obtain a license from RSA
> granting them permission to use the RSA algorithm.)
>
> 5) csmime.mdl contains SFL Class diagrams created using Microsoft
> Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools).
> The file can also be viewed using Rational Rose C++ Demo 4.0
> 45 day evaluation copy which can be obtained from
> <http://www.rational.com/uml/resources/practice_uml/index.jtmpl>.
> Not all classes are documented in the MDL file at this time.
>
> All source code for the SFL is being provided at no cost and with no
> financial limitations regarding its use and distribution.
> Organizations can use the SFL without paying any royalties or
> licensing fees.  VDA is developing the SFL under contract to the U.S.
> Government.  The U.S. Government is furnishing the SFL source code at no
> cost to the vendor subject to the conditions of the "SFL Public
> License" available from the VDA SFL Page and Fortezza Developer's
> S/MIME Page.
>
> The SFL is composed of a high-level library that performs generic CMS
> and ESS processing independent of the crypto algorithms used to
> protect a specific object.  The SFL high-level library makes calls to
> an algorithm-independent CTIL API.  The underlying, external crypto
> token libraries are not distributed as part of the SFL
> source code. The application developer must independently obtain these
> libraries and then link them with the SFL.  For example, the SFL uses
> the freeware Crypto++ library to obtain 3DES, D-H and DSA.  To use
> the SFL with Crypto++ the vendor must download the Crypto++ freeware
> library from the Crypto++ Web Page and then compile it with the
> VDA-developed Crypto++ CTIL source code.
>
> The Internet Mail Consortium (IMC) has established an SFL web page
> <http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
> mail list which is used to: distribute information regarding SFL
> releases; discuss SFL-related issues; and provide a means for SFL
> users to provide feedback, comments, bug reports, etc.  Subscription
> information for the imc-sfl mailing list is at the IMC web site
> listed above.
>
> The SFL documents and VDA-enhanced SNACC source code are also
> available from the VDA SFL Web Page
> <http://www.jgvandyke.com/services/infosec/sfl.htm>.
>
> All comments regarding the SFL source code and documents are welcome.
> We recommend that comments should be sent to the imc-sfl mail list.
> We will respond to all messages on that list.
>
> ============================================
> John Pawling, Director - Systems Engineering
> J.G. Van Dyke & Associates, Inc;
> a Wang Government Services Company
> [e-mail]
> ============================================

--------------8B518FEC5C6CAE5D1E8289D6
Content-Type: text/x-vcard; charset=us-ascii;
 name="gyee.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Guang Yee
Content-Disposition: attachment;
 filename="gyee.vcf"

begin:vcard 
n:Yee;Guang
tel;work:[phone]
x-mozilla-html:FALSE
url:messaging.us.oracle.com
org:Oracle;Email Server
version:2.1
email;internet:[e-mail]
title:Senior Member of Technical Staff
adr;quoted-printable:;;600 Oracle Parkway=0D=0AM/S: 6op3;Redwood Shores;CA;94065;U.S.A
fn:Guang Yee
end:vcard

--------------8B518FEC5C6CAE5D1E8289D6--



Received: by ns.secondary.com (8.9.3/8.9.3) id SAA02547 for ietf-smime-bks; Wed, 22 Mar 2000 18:08:08 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02540 for <[e-mail]>; Wed, 22 Mar 2000 18:08:07 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id SAA15724; Wed, 22 Mar 2000 18:09:25 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 21 Mar 2000 11:18:41 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-smime-seclabel-00.txt
Cc: [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>

Weston:

I have two questions about the Internet-Draft.

QUESTION 1.

The Amoco policy defines confidentiality hierarchy and an integrity 
hierarchy.  In practice, is a piece of information marked with a 
confidentiality value, an integrity value, or both?  The ASN.1 defined in 
the document leads me to believe that a particular piece of information has 
either a confidentiality value or an integrity value, but never both.

You included the following ASN.1:
      Amoco-SecurityClassification ::=  {
        amoco general (6),
        amoco confidential (7),
        amoco highly confidential (8),
        amoco minimum (9),
        amoco medium (10),
        amoco maximum (11)  }

Since the classification in the ESS security label is a single INTEGER, 
only one of these values may be present in a particular instance of a 
security label.

Is the integrity value ever used to make an access control decision?  If 
not, then perhaps the integrity value should be carried in the privacy mark.

QUESTION 2.

In the Whirlpool section, you say:

      For WHIRLPOOL INTERNAL, additional markings or caveats are option at the
      discretion of the information owner.

      For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as 
necessary to
      comply with regulatory or heightened security 
requirements.  Examples:  MAKE NO
      COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
      DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT.

The examples listed can be characterized as guidance to the information 
recipient about how the needs to be handled.  Mostly, guidance is provided 
about the redistribution of the information.  Since these are examples, I 
wonder if there is a example of a caveat on which one might expect 
automated access control.

Russ 


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA16941 for ietf-smime-bks; Fri, 17 Mar 2000 08:31:03 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16937 for <[e-mail]>; Fri, 17 Mar 2000 08:31:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 17 Mar 2000 09:31:53 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 17 Mar 2000 09:31:43 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: S/MIME v3 Interoperability Testing (was RE: S/MIMEexamples draft )
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16938
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>

It occurs to me that this effort would be extremely useful in trying to 
further the interoperability testing that the PKI Forum is being set up 
to do.

What would be really great would be if we could go beyond examples, and
try to develop actual test cases.  Or maybe contribute test cases that we 
have developed internally.

As an example of the kind of obscure things that can bite you, I recently 
tried to gather up an entire set of encrypted correspondence by 
sending a encrypted message to myself with 30 or so encrypted attachments
that I dragged on to the attachment window.

Didn't work.  Only one message showed up in the attachments. So there's one 
bug to more to fix.

Why would you want to do such a thing?  For compactness and archiving ,
and perhaps to hide the plaintext headers that show who you were 
communicating with.

Bob


>>> Russ Housley <[e-mail]> 03/15/00 12:06PM >>>
John:

John, as S/MIME WG chairman, I greatly appreciate your commitment.  I hope 
that other implementors will join in this effort.  Collecting this data is 
essential for the specifications to progress from Proposed Standard to 
Draft Standard, so we might as well help implementors that come behind us.

Russ

At 09:45 AM 03/14/2000 -0500, Pawling, John wrote:
>Paul (and friends),
>
>We believe that the "Examples of S/MIME Messages" document should be
>enhanced and maintained.  We believe that it is extremely valuable to have a
>set of properly formatted sample S/MIME messages which can be used to test
>S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
>successfully process (i.e. decode, verify, decrypt) the majority of the
>samples in the document.  I use the term "the majority" because the SFL does
>not support every S/MIME v3 optional feature.  For example, the SFL does not
>support the CMS authenticatedData content type.  We have also used the SFL
>to construct sample data (such as signed receipts) to be added to the
>document.  We have automated this SFL testing (through the use or test
>drivers and configuration files) so that it can be easily repeated and
>modified by us or independently by a third party (we provide all source
>code, unencumbered).  We are willing to spend time providing sample data to
>be included in the Examples document and to provide support when there are
>questions regarding the validity of the sample data.  We are also willing to
>participate in interoperability testing with others.
>
>We apologize for not providing feedback and submitting sample data sooner.
>We have been using the SFL to perform S/MIME v3 interoperability testing
>with Microsoft that has exercised the majority of the features specified by
>RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
>RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
>until we finished interoperability testing with Microsoft to submit the
>SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
>2634 (ESS) signed receipt interoperability testing between the SFL and
>Microsoft.  This was the last major S/MIME v3 item that needed to be tested
>between the SFL and Microsoft.  We plan to provide sample signed receipts
>for inclusion in the Examples document.  We have also performed limited
>S/MIME v3 testing with Baltimore and Entrust.
>
>We still need to perform countersignature interoperability testing.  We plan
>to pursue this testing with Microsoft.  If anybody else can process
>countersignatures, please let us know.  We are not going to wait until this
>testing is done before submitting SFL-produced sample data for inclusion in
>the Examples document.
>
>As many of you know, Jim Schaad created a detailed set of matrices to
>document the interoperabilty testing performed between various
>implementations. There is a matrix for each S/MIME v3 specification.  These
>matrices are much more detailed than the "Examples of S/MIME Messages"
>document.  We have verified that the SFL can produce and process the
>majority of the features documented in the compliance matrices.  Again, I
>use the term "the majority" because the SFL does not support every S/MIME v3
>optional feature.  We have automated this SFL testing so that it can be
>easily repeated and modified by us or independently by a third party.  We
>have developed sample objects that illustrate each feature in the matrix
>that the SFL supports.
>
>Please note that Jim Schaad's matrices are a superset of the Examples
>document.  Does the group want to include all of Jim's tests in the Examples
>document?  If so, we can provide the sample data to illustrate each feature
>in the matrix that the SFL supports.  Please note that this document would
>be huge, but it would provide a comprehensive set of test data.  What do
>others think?
>
>We will have the SFL-produced test data ready for distribution by 24 March
>2000 at the latest.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[e-mail] 
>============================================
>



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA15767 for ietf-smime-bks; Thu, 16 Mar 2000 10:40:30 -0800 (PST)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15762; Thu, 16 Mar 2000 10:40:27 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJJ57H>; Thu, 16 Mar 2000 13:41:22 -0500
Message-ID: <[e-mail]>
From: =?UTF-8?B?UGF3bGluZywgSm9obg==?= <[e-mail]>
To: =?UTF-8?B?J0NhbWVyb24gU3RpbGxpb24n?= <[e-mail]>, =?UTF-8?B?J2lldGYtc21pbWVAaW1jLm9yZyc=?= <[e-mail]>
Cc: =?UTF-8?B?J3Bob2ZmbWFuQGltYy5vcmcn?= <[e-mail]>, =?UTF-8?B?QnJ5YW4gU3RhYXRz?= <[e-mail]>
Subject: =?UTF-8?B?UkU6IEVTUyA6IFNlY3VyZSBSZWNlaXB0IGVuY29kaW5nIHdpdGhp?= =?UTF-8?B?biBFbmNhcHN1bGF0ZWRDb250ZW50SW5mbw==?=
Date: Thu, 16 Mar 2000 13:41:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="UTF-8"
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>

Cameron,
 
The signedData encapContentInfo eContent field is defined as an OCTET STRING
in RFC 2630 (CMS).   If the eContent field is present, then the OCTET STRING
tag and length octets must be present in the encoding of the signedData.
RFC 2630 Section 2 states: "As a general design philosophy, each content
type permits single pass processing using indefinite-length Basic Encoding
Rules (BER) encoding." and "Signed attributes and authenticated attributes
are the only CMS data types that require DER encoding."  Therefore, the
signedData content type (including the encapContentInfo eContent OCTET
STRING tag and length octets) does not need to be DER-encoded.  
 
As you correctly point out, RFC 2634 (ESS) requires that the Receipt content
type must be DER-encoded within the signedData encapContentInfo eContent
OCTET STRING.


============================================ 
John Pawling, Director - Systems Engineering 
J.G. Van Dyke & Associates, Inc; 
a Wang Government Services Company 
[e-mail] <mailto:[e-mail]>  
============================================ 

-----Original Message-----
From: Cameron Stillion [ mailto:[e-mail]
<mailto:[e-mail]> ]
Sent: Thursday, March 09, 2000 9:15 PM
To: '[e-mail]' <mailto:'[e-mail]'> 
Cc: '[e-mail]'; Bryan Staats
Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo


... and now for something completely different:
 
According to the ESS RFC on page 16, step 9:
 
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].
 
Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
 
The word "directly" seems to indicate that the former is the correct one.
Just tell me I'm not crazy.
 
Cameron Stillion
 



Received: by ns.secondary.com (8.9.3/8.9.3) id EAA02297 for ietf-smime-bks; Thu, 16 Mar 2000 04:00:33 -0800 (PST)
Received: from mailserver.ipf.net (smtp.itl-online.de [195.211.211.86]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA02292 for <[e-mail]>; Thu, 16 Mar 2000 04:00:31 -0800 (PST)
Message-Id: <[e-mail]>
Received: (qmail 21084 invoked from network); 16 Mar 2000 11:52:23 -0000
Received: from dialin-194-29-49-241.hannover.gigabell.net (HELO localhost) (194.29.49.241) by mail.okay.net with SMTP; 16 Mar 2000 11:52:23 -0000
From: "Alexander" <[e-mail]>
To: "A good opportunity for u" <[e-mail]>
Date: Thu, 16 Mar 2000 12:51:29 +0100
Subject: Surfingprize brand new Get-paid-programm (very good)
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 1
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>

SurfingPrizes:

A viewBar type that:
The referral structure is 5 levels deep:
For your surfing time, you'll receive $0.20 per hour;
for your direct referrals, you'll earn $0.04/hour;
and for your indirect referrals you'll earn $0.02/hour.
For 5 levels deep!

ViewBar Ver 1.0 Avalible for Win 95,98,NT

Site is well laid out and snappy.
I'm only number 786 in this one.

Sign-up Here: http://www.surfingprizes.com/r/?100786

Thanks for sign-up under me
Alexander 	[e-mail]  





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA20381 for ietf-smime-bks; Thu, 16 Mar 2000 00:41:01 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA20377 for <[e-mail]>; Thu, 16 Mar 2000 00:41:00 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Mar 2000 00:38:22 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <GRS23VXR>; Thu, 16 Mar 2000 00:38:22 -0800
Message-ID: <E46F2E74BFC4CF119A8B00805FCCAB2708DC73E2@RENCHOW>
From: =?utf-8?B?Q2FtZXJvbiBTdGlsbGlvbg==?= <[e-mail]>
To: =?utf-8?B?J2lldGYtc21pbWVAaW1jLm9yZyc=?= <[e-mail]>
Cc: =?utf-8?B?J3Bob2ZmbWFuQGltYy5vcmcn?= <[e-mail]>, =?utf-8?B?QnJ5YW4gU3RhYXRz?= <[e-mail]>
Subject: =?utf-8?B?RVNTIDogU2VjdXJlIFJlY2VpcHQgZW5jb2Rpbmcgd2l0aGluIEVu?= =?utf-8?B?Y2Fwc3VsYXRlZENvbnRlbnRJbmZv?=
Date: Thu, 9 Mar 2000 18:15:23 -0800 
X-MS-TNEF-Correlator: <E46F2E74BFC4CF119A8B00805FCCAB2708DC73E2@RENCHOW>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8F22.FC7C8624"
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_000_01BF8F22.FC7C8624
Content-Type: text/plain;
	charset="utf-8"

... and now for something completely different:
 
According to the ESS RFC on page 16, step 9:
 
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].
 
Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
 
The word "directly" seems to indicate that the former is the correct one.
Just tell me I'm not crazy.
 
Cameron Stillion
 

------_=_NextPart_000_01BF8F22.FC7C8624
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhcIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEFgAMADgAAANAHAwAJABIA
DwAXAAQAHwEBCYABACEAAAA1RjJBNEIwNjhCRjVEMzExOUIzMjAwODA1RkQ0NTlGRQAsBwEggAMA
DgAAANAHAwAQAAAAJgAVAAQAKQEBDYAEAAIAAAACAAIAAQOQBgDMDgAAOgAAAAsAAgABAAAAAgEx
AAEAAABGAAAAAAAAAEyiHl/8uc8RmUsAAAAAAAEHAC79ARQFJM8RmRAAqgBsgNEAAAC+0DMAAORv
LnS/xM8RmosAgF/MqycAAAjOXX8AAAAAQAA5AHA6yX02ir8BHwAxQAEAAAASAAAAQwBBAE0ARQBS
AE8AUwBUAAAAAAADABpAAAAAAB8AMEABAAAAEgAAAEMAQQBNAEUAUgBPAFMAVAAAAAAAAwAZQAAA
AAAfAEsAAQAAAAIAAAAAAAAAHwBwAAEAAAB6AAAARQBTAFMAIAA6ACAAUwBlAGMAdQByAGUAIABS
AGUAYwBlAGkAcAB0ACAAZQBuAGMAbwBkAGkAbgBnACAAdwBpAHQAaABpAG4AIABFAG4AYwBhAHAA
cwB1AGwAYQB0AGUAZABDAG8AbgB0AGUAbgB0AEkAbgBmAG8AAAAAAAIBcQABAAAAFgAAAAG/igJB
XPhvcFf1zBHThDoAYLDsDf8AAAIBCRABAAAARQYAAEEGAAB3GwAATFpGdeotMT4DAAoAcmNwZzEy
NYIyA0NodG1sMQMwPwEDAfcKgAKkA+MCAGNowQrAc2V0MCAHEwKA/xADAFAEVghVB7IR1Q5RAwHd
ENcyBgAGwxHVMwRGENn5Eu9mNBBvEXYR4wjvCfe2Oxq/DjA1EdIMYGMAUDMLCQFkMzYRYAulNCBZ
EAIqXA6yAZBnH2AzACA8IURPQ1RZAFBFIEhUTUwgAFBVQkxJQyAiQC0vL1czQyIgRCRURCE0NC4R
YFRyOQBydGkCIAdAIiBFTnwiPhHjH9cggAqjJIwxPjkgkCFCJH4fcCbgRUG+RCR9DvElnymPJmQ2
DvDAPE1FVEEgBaACMLEJ8HQ9IgXgIUM1IzAQMC4yOSawLjYzMDA3IiAj8AeAPUeBJEBFUkFUT1Ik
fXo0LFEvKG8gQSr/IDE1wRFgPEJPRFkkfR7hETJfZzk2IJBESVb3JHAf4wAhIAAANtURYB+5nDY0
Nr83wiXsNDggkMBGT05UIGYA0C8AvwcTNqsYMAMwOZ8gEzgoMXBTUEFOLMALYAQQPbEe0Dk1MzNw
JrAtP6C8MDMB0C3wNq83sy5CEOogAHBkLsBvB+ACEAXA1nMDcBFAaAuAZx+MPREbNRMFoG0LUBFA
ZWx5tCBkBpBmBJAtETo1bL8U8DDQPuJAuUDHOg41NkH+LztCR783vgHAQMcKokho+wqAJewwKDEi
gDaLSG80f/81jzafS484v1CvOt877zz//z4PPx9AL1Y/Ro9Hn16fSb+DYK9avyZuYnNwAoDxXcdc
J2EBQFRvTG9Nf/9Oj0+fZD9Rv1LPXe9U729v/1cPWB9ZL3IfW09cX11vb/ecQWMFoUWwQ4F0b3sg
IGhlIEVTBfBSRt8h4AIgQ69tkwqwZ3uALDDGLEMALQBwIDlGT2AP/2vvYi+AD2cvaD9pT2pfgw//
bH9tj26fb69wv3HPct9z7/90/48fdx94L4vvks9/b4hv/4GPgp+Zj2UfZi+D/4UPhh//hy+bz4lP
il+Lb4x/jY+Wj/+Pr5C/kc+qv5PvlP+pr6iSPy5QnO+d/58KI1B7cUFT9E4uDvBEL1B8T6XjCfDX
BaABAEJwUgWQZQUiLNXpBdBVU6xAYnuARbAawPxjdEWBuCYD8ENSe1MAkORnbgmARGEBkLbPt9bM
YXAIUCzzSW4CELqgHb41ICDRLJAGAFRSSXxOR0WgARALgLhxu3Fb+kMF4F2y/JgvpA+aT5tf/6hf
oF+hb6J/xZ/D36Wvpr//sd+o387/sw+0H58Px0/IX//Jb8p/0Z/Mn82v0N/Pz9zP/9nvq8+s363v
rv+wD7Ef3Vr0U2gIYGxCcL73ufG8f9vbFLaRLbgjQ3Jv3UB7Yvu6QbjSP8Fvwn/jT8Sf7f//1M/V
39bv1//w/9of2y/cP//dT95f32/gf+GP4p/9D+S//+XP+/8Av9L/1A4FPwZPB1//CG8Jf7V26X/4
QkLg7I/tn/8KX++/EM/x3/Lv8//1DxPP//cv+D/5T/pf+28Eb/2P/p///68f3wHPAt8ez+fv6P/q
D+/rGUJQv3y5ImHA0HrztgH/6s+2ASlfGxLsDw/vGO8SD/8THxQvFT8WTxdfGG8y3xqP/xufJr8d
vz3/Ox8g7yH/Iw//JB8lLyY/QK8w/zn/SQ80L/9LHwsPDB/UXzafN684vznP/05vO+88/0gfPx9Z
n0vvQk9/Q19Eb0V/Ro9Hn1xJtfJ3KXrBICK6JiJ+IGVl/G1zLs9X43sxwNB64L4AH7lQe1G8UHtT
vsBybWV9WABpZmB7YnqxukJ8EWVnsv9P77UcSnV+MHsgZQhsbCBpUCBJJ204IG5vuYBmj1fyY3L4
YXp5wV9KX1Y/TH9yH/9Rf1KPU59Ur3UfVs9X31jv/1n/Ww9cH10vXj9fT4EvYW//Yn99/4TfcX96
f3OfdK+Ln/9rT2xfdg93H3gveT+N33tf/3xvfX9+j3+fiJ+Bv4LPg9+fnM+F/4cPm7+aokNhaVFH
aoBu/5fzU3RpbiBp/2qAiW+Kf6AfjJ+ov5Gfkq//k7+Uz6u/lu+X/5kPmh+bL/+cP48/kE+1b61v
rn+vj7CfCbe/ZzWd8S9CT0QmWZ8QsfsyN75BSFRUTUzBbTOy1X3EYAAAAAIBFDoBAAAAEAAAAF8q
SwaL9dMRmzIAgF/UWf4DAN4/6f0AAAMAJgAAAAAAAwA2AAAAAAADAPE/CQQAAAMA/T/kBAAAAwAC
WQAAFgADAAlZAwAAAAMAAW4gAgAACwAFgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAACA
CCAGAAAAAADAAAAAAAAARgAAAABShQAAHm4BAB8AAYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB
AAAACAAAADkALgAwAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAA
AADAAAAAAAAARgAAAAADhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAG
gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAiACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA
AAAAAAsAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAHwAOgAggBgAAAAAAwAAAAAAAAEYA
AAAAg4UAAAEAAAAmAAAANgAwADkANQAzADUAMAAxADkALQAwADkAMAAzADIAMAAwADAAAAAAAAMA
gBD/////CwDyEAEAAAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAAAfAPMQAQAAAIYAAABFAFMAUwAg
ACUAMwBBACAAUwBlAGMAdQByAGUAIABSAGUAYwBlAGkAcAB0ACAAZQBuAGMAbwBkAGkAbgBnACAA
dwBpAHQAaABpAG4AIABFAG4AYwBhAHAAcwB1AGwAYQB0AGUAZABDAG8AbgB0AGUAbgB0AEkAbgBm
AG8ALgBFAE0ATAAAAAAAAgFHAAEAAAAyAAAAYz1VUzthPSA7cD1NaWNyb3NvZnQ7bD1SRU5DSE9X
LTAwMDMxMDAyMTUyM1otMTA3OQAAAAIB+T8BAAAATQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAA
AAAAAAAvTz1NSUNST1NPRlQvT1U9T0ZGSUNFL0NOPVJFQ0lQSUVOVFMvQ049Q0FNRVJPU1QAAAAA
HwD4PwEAAAA4AAAAQwBhAG0AZQByAG8AbgAgAFMAdABpAGwAbABpAG8AbgAgACgARQB4AGMAaABh
AG4AZwBlACkAAAAfADhAAQAAABIAAABDAEEATQBFAFIATwBTAFQAAAAAAAIB+z8BAAAATQAAAAAA
AADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1NSUNST1NPRlQvT1U9T0ZGSUNFL0NOPVJFQ0lQ
SUVOVFMvQ049Q0FNRVJPU1QAAAAAHwD6PwEAAAA4AAAAQwBhAG0AZQByAG8AbgAgAFMAdABpAGwA
bABpAG8AbgAgACgARQB4AGMAaABhAG4AZwBlACkAAAAfADlAAQAAABIAAABDAEEATQBFAFIATwBT
AFQAAAAAAEAABzDQM2Z5Noq/AUAACDAkhnz8Io+/AR8AGgABAAAAEgAAAEkAUABNAC4ATgBPAFQA
RQAAAAAAHwA3AAEAAAB6AAAARQBTAFMAIAA6ACAAUwBlAGMAdQByAGUAIABSAGUAYwBlAGkAcAB0
ACAAZQBuAGMAbwBkAGkAbgBnACAAdwBpAHQAaABpAG4AIABFAG4AYwBhAHAAcwB1AGwAYQB0AGUA
ZABDAG8AbgB0AGUAbgB0AEkAbgBmAG8AAAAAAB8APQABAAAAAgAAAAAAAAAfAB0OAQAAAHoAAABF
AFMAUwAgADoAIABTAGUAYwB1AHIAZQAgAFIAZQBjAGUAaQBwAHQAIABlAG4AYwBvAGQAaQBuAGcA
IAB3AGkAdABoAGkAbgAgAEUAbgBjAGEAcABzAHUAbABhAHQAZQBkAEMAbwBuAHQAZQBuAHQASQBu
AGYAbwAAAAAAHwA1EAEAAABmAAAAPABFADQANgBGADIARQA3ADQAQgBGAEMANABDAEYAMQAxADkA
QQA4AEIAMAAwADgAMAA1AEYAQwBDAEEAQgAyADcAMAA4AEQAQwA3ADMARQAyAEAAUgBFAE4AQwBI
AE8AVwA+AAAAAAALACkAAAAAAAsAIwAAAAAAAwAGEMu/X3MDAAcQnQEAAAMAEBADAAAAAwAREAAA
AAAeAAgQAQAAAGUAAABBTkROT1dGT1JTT01FVEhJTkdDT01QTEVURUxZRElGRkVSRU5UOkFDQ09S
RElOR1RPVEhFRVNTUkZDT05QQUdFMTYsU1RFUDk6OVRIRUFTTjFERVJFTkNPREVEUkVDRUlQVENP
AAAAAAIBfwABAAAAMwAAADxFNDZGMkU3NEJGQzRDRjExOUE4QjAwODA1RkNDQUIyNzA4REM3M0Uy
QFJFTkNIT1c+AABkEQ==

------_=_NextPart_000_01BF8F22.FC7C8624--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA22216 for ietf-smime-bks; Wed, 15 Mar 2000 17:17:03 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22201 for <[e-mail]>; Wed, 15 Mar 2000 17:17:02 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id RAA02559; Wed, 15 Mar 2000 17:17:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 15 Mar 2000 14:06:49 -0500
To: "Pawling, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: S/MIME v3 Interoperability Testing (was RE: S/MIME examples draft )
Cc: [e-mail]
In-Reply-To: <[e-mail] m>
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>

John:

John, as S/MIME WG chairman, I greatly appreciate your commitment.  I hope 
that other implementors will join in this effort.  Collecting this data is 
essential for the specifications to progress from Proposed Standard to 
Draft Standard, so we might as well help implementors that come behind us.

Russ

At 09:45 AM 03/14/2000 -0500, Pawling, John wrote:
>Paul (and friends),
>
>We believe that the "Examples of S/MIME Messages" document should be
>enhanced and maintained.  We believe that it is extremely valuable to have a
>set of properly formatted sample S/MIME messages which can be used to test
>S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
>successfully process (i.e. decode, verify, decrypt) the majority of the
>samples in the document.  I use the term "the majority" because the SFL does
>not support every S/MIME v3 optional feature.  For example, the SFL does not
>support the CMS authenticatedData content type.  We have also used the SFL
>to construct sample data (such as signed receipts) to be added to the
>document.  We have automated this SFL testing (through the use or test
>drivers and configuration files) so that it can be easily repeated and
>modified by us or independently by a third party (we provide all source
>code, unencumbered).  We are willing to spend time providing sample data to
>be included in the Examples document and to provide support when there are
>questions regarding the validity of the sample data.  We are also willing to
>participate in interoperability testing with others.
>
>We apologize for not providing feedback and submitting sample data sooner.
>We have been using the SFL to perform S/MIME v3 interoperability testing
>with Microsoft that has exercised the majority of the features specified by
>RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
>RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
>until we finished interoperability testing with Microsoft to submit the
>SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
>2634 (ESS) signed receipt interoperability testing between the SFL and
>Microsoft.  This was the last major S/MIME v3 item that needed to be tested
>between the SFL and Microsoft.  We plan to provide sample signed receipts
>for inclusion in the Examples document.  We have also performed limited
>S/MIME v3 testing with Baltimore and Entrust.
>
>We still need to perform countersignature interoperability testing.  We plan
>to pursue this testing with Microsoft.  If anybody else can process
>countersignatures, please let us know.  We are not going to wait until this
>testing is done before submitting SFL-produced sample data for inclusion in
>the Examples document.
>
>As many of you know, Jim Schaad created a detailed set of matrices to
>document the interoperabilty testing performed between various
>implementations. There is a matrix for each S/MIME v3 specification.  These
>matrices are much more detailed than the "Examples of S/MIME Messages"
>document.  We have verified that the SFL can produce and process the
>majority of the features documented in the compliance matrices.  Again, I
>use the term "the majority" because the SFL does not support every S/MIME v3
>optional feature.  We have automated this SFL testing so that it can be
>easily repeated and modified by us or independently by a third party.  We
>have developed sample objects that illustrate each feature in the matrix
>that the SFL supports.
>
>Please note that Jim Schaad's matrices are a superset of the Examples
>document.  Does the group want to include all of Jim's tests in the Examples
>document?  If so, we can provide the sample data to illustrate each feature
>in the matrix that the SFL supports.  Please note that this document would
>be huge, but it would provide a comprehensive set of test data.  What do
>others think?
>
>We will have the SFL-produced test data ready for distribution by 24 March
>2000 at the latest.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[e-mail]
>============================================
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA10164 for ietf-smime-bks; Tue, 14 Mar 2000 06:44:58 -0800 (PST)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10160 for <[e-mail]>; Tue, 14 Mar 2000 06:44:56 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJJP6V>; Tue, 14 Mar 2000 09:45:41 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: S/MIME v3 Interoperability Testing (was RE: S/MIME examples draft )
Date: Tue, 14 Mar 2000 09:45:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
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>

Paul (and friends),

We believe that the "Examples of S/MIME Messages" document should be
enhanced and maintained.  We believe that it is extremely valuable to have a
set of properly formatted sample S/MIME messages which can be used to test
S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
successfully process (i.e. decode, verify, decrypt) the majority of the
samples in the document.  I use the term "the majority" because the SFL does
not support every S/MIME v3 optional feature.  For example, the SFL does not
support the CMS authenticatedData content type.  We have also used the SFL
to construct sample data (such as signed receipts) to be added to the
document.  We have automated this SFL testing (through the use or test
drivers and configuration files) so that it can be easily repeated and
modified by us or independently by a third party (we provide all source
code, unencumbered).  We are willing to spend time providing sample data to
be included in the Examples document and to provide support when there are
questions regarding the validity of the sample data.  We are also willing to
participate in interoperability testing with others.

We apologize for not providing feedback and submitting sample data sooner.
We have been using the SFL to perform S/MIME v3 interoperability testing
with Microsoft that has exercised the majority of the features specified by
RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
until we finished interoperability testing with Microsoft to submit the
SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
2634 (ESS) signed receipt interoperability testing between the SFL and
Microsoft.  This was the last major S/MIME v3 item that needed to be tested
between the SFL and Microsoft.  We plan to provide sample signed receipts
for inclusion in the Examples document.  We have also performed limited
S/MIME v3 testing with Baltimore and Entrust. 

We still need to perform countersignature interoperability testing.  We plan
to pursue this testing with Microsoft.  If anybody else can process
countersignatures, please let us know.  We are not going to wait until this
testing is done before submitting SFL-produced sample data for inclusion in
the Examples document.

As many of you know, Jim Schaad created a detailed set of matrices to
document the interoperabilty testing performed between various
implementations. There is a matrix for each S/MIME v3 specification.  These
matrices are much more detailed than the "Examples of S/MIME Messages"
document.  We have verified that the SFL can produce and process the
majority of the features documented in the compliance matrices.  Again, I
use the term "the majority" because the SFL does not support every S/MIME v3
optional feature.  We have automated this SFL testing so that it can be
easily repeated and modified by us or independently by a third party.  We
have developed sample objects that illustrate each feature in the matrix
that the SFL supports.      

Please note that Jim Schaad's matrices are a superset of the Examples
document.  Does the group want to include all of Jim's tests in the Examples
document?  If so, we can provide the sample data to illustrate each feature
in the matrix that the SFL supports.  Please note that this document would
be huge, but it would provide a comprehensive set of test data.  What do
others think?

We will have the SFL-produced test data ready for distribution by 24 March
2000 at the latest.  

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 





Received: by ns.secondary.com (8.9.3/8.9.3) id UAA09781 for ietf-smime-bks; Mon, 13 Mar 2000 20:19:21 -0800 (PST)
Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA09774 for <[e-mail]>; Mon, 13 Mar 2000 20:19:19 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 13 Mar 2000 20:20:38 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: S/MIME examples 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>

There has been essentially no input to this draft in a very long time. The 
vast majority of the input came from Jim Schaad, who is no longer in the 
S/MIME world. Thus, I believe that the draft is probably dead. If other 
S/MIME developers want to contribute examples where there are holes and 
comments for the examples that are there, I'm happy to continue the draft, 
but otherwise we might just let this go away.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: by ns.secondary.com (8.9.3/8.9.3) id OAA26275 for ietf-smime-bks; Mon, 13 Mar 2000 14:37:03 -0800 (PST)
Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26038; Mon, 13 Mar 2000 14:32:32 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 13 Mar 2000 14:33:51 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: New draft on ASN.1 pitfalls
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>

Timing is everything. Just as the PKIX mailing list starts to talk about 
ASN.1 again, a new draft comes out that does a good job of listing some of 
the ASN.1 gotchas to look out for, as well as why ASN.1 isn't necessarily a 
great format to use (although it's a tad too late for that now...). Anyhow, 
take a look at 
<http://www.ietf.org/internet-drafts/draft-yu-asn1-pitfalls-00.txt>. The 
author said he's open to adding any PKIX-specific and S/MIME-specific 
warnings to the document.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22696 for ietf-smime-bks; Mon, 13 Mar 2000 12:18:54 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22692 for <[e-mail]>; Mon, 13 Mar 2000 12:18:53 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA02350 for <[e-mail]>; Mon, 13 Mar 2000 12:19:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 13 Mar 2000 15:15:34 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: LAST CALL:draft-ietf-smime-password-02.txt
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>

The Password-based Encryption for S/MIME specification is ready for Working 
Group Last Call.  Please post comments to the ietf-smime mail list before 
27 March 2000.

Russ

= = = = = = = = = =

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-02.txt
	Pages		: 9
	Date		: 10-Mar-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.




Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16323 for ietf-smime-bks; Mon, 13 Mar 2000 07:45:56 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16319 for <[e-mail]>; Mon, 13 Mar 2000 07:45:55 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA28672; Mon, 13 Mar 2000 07:45:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 13 Mar 2000 10:43:16 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: S/MIME WG Agenda
Cc: [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>

             S/MIME Mail Security WG Agenda

Introductions                           Russ Housley
Working Group Status                    Russ Housley
Security Policies and Labels            Russ Housley
CERTDIST Draft Discussion               Jim Schaad
Symmetric Key Distribution              Sean Turner
DOMSEC Draft Discussion                 Bill Ottaway
Interoperability Matrix                 Jim Schaad
CMS/ESS Examples                                Paul Hoffman
Crypto Algorithm Documents              Russ Housley
E-mail Addresses & Certificates Greg Colla
S/MIME Freeware Library         John Pawling
Electronic Signature Formats            Denis Pinkas
Wrap up                                 Russ Housley


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09568 for ietf-smime-bks; Mon, 13 Mar 2000 03:18:36 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09563 for <[e-mail]>; Mon, 13 Mar 2000 03:18:35 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15402; Mon, 13 Mar 2000 06:19:39 -0500 (EST)
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-password-02.txt
Date: Mon, 13 Mar 2000 06:19:38 -0500
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		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-02.txt
	Pages		: 9
	Date		: 10-Mar-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.

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-password-02.txt

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-password-02.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09560 for ietf-smime-bks; Mon, 13 Mar 2000 03:18:31 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09556 for <[e-mail]>; Mon, 13 Mar 2000 03:18:30 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15379; Mon, 13 Mar 2000 06:19:34 -0500 (EST)
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-cms-rsaes-oaep-00.txt
Date: Mon, 13 Mar 2000 06:19:33 -0500
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		: CMS RSAES-OAEP Conventions
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-00.txt
	Pages		: 8
	Date		: 10-Mar-00
	
This document describes the use of the RSAES-OAEP key transport
method of key management within the Cryptographic Message Syntax
[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/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-rsaes-oaep-00.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-cms-rsaes-oaep-00.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-cms-rsaes-oaep-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12943 for ietf-smime-bks; Fri, 10 Mar 2000 03:29:40 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12938 for <[e-mail]>; Fri, 10 Mar 2000 03:29:39 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29584; Fri, 10 Mar 2000 06:30:29 -0500 (EST)
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-esformats-00.txt
Date: Fri, 10 Mar 2000 06:30:29 -0500
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		: Electronic Signature Formats for long term electronic 
                          signature
	Author(s)	: J. Ross, D. Pinkas, N. Pope
	Filename	: draft-ietf-smime-esformats-00.txt
	Pages		: 106
	Date		: 09-Mar-00
	
The informational RFC defines the format of an electronic signature 
that can remain valid over long periods. This includes evidence as to 
its validity even if the signer or verifying party later attempts to 
deny (repudiates) the validity of the signature.

The contents of this Informational RFC is technically equivalent to 
ETSI ES 201 733 V.1.1.1 Copyright (C). Individual copies of this 
ETSI deliverable can be downloaded from http://www.etsi.org

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-esformats-00.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-esformats-00.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-esformats-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29228 for ietf-smime-bks; Thu, 9 Mar 2000 23:17:41 -0800 (PST)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29224 for <[e-mail]>; Thu, 9 Mar 2000 23:17:40 -0800 (PST)
Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id XAA10087; Thu, 9 Mar 2000 23:18:26 -0800 (PST)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: Aram Perez <[e-mail]>, [e-mail]
Date: Thu, 9 Mar 2000 23:18:29 +0800
Subject: RE: Triple Wrapping Survey
Message-id: <[e-mail]>
X-User-Info: 210.55.166.93
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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>

>Hi Russ,
>
>I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
>understand MIME, all implementations should handle binary as this is the
>default unless otherwise specified.

There are some known existing implemenations which cannot correctly handle the
binary versions.  I do not know any longer how wide spread these versions are.


jim

>
>Regards,
>Aram Perez
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Monday, March 06, 2000 7:21 PM
>To: [e-mail]
>Subject: Triple Wrapping Survey
>
>
>I have a few questions for implementors.  First some background, then the 

>questions.
>
>The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME

>encodings.  If each of these encodings uses Base64, then the overhead is 
>huge.  I am interested in ways to reduce the overhead, hopefully without 
>hurting IMAP usability.
>
>1.  Can your implementation handle
>	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?
>
>The outer SignedData has the OID for EnvelopedData in the content type, not

>id-data.
>The EnvelopedData has the OID for SignedData in the content type, not
>id-data.
>The inner Signed Data has the id-data OID in the content type.
>
>2.  Can your implementation handle MIME without Base64 encoding?  I am 
>interested in using "binary" instead of Base64 to reduce the overhead.
>
>Russ
>
>
http://www.nwlink.com


Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29161 for ietf-smime-bks; Thu, 9 Mar 2000 23:15:57 -0800 (PST)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29154 for <[e-mail]>; Thu, 9 Mar 2000 23:15:56 -0800 (PST)
Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id XAA09953; Thu, 9 Mar 2000 23:16:43 -0800 (PST)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: Russ Housley <[e-mail]>, [e-mail]
Date: Thu, 9 Mar 2000 23:16:43 +0800
Subject: Re: Triple Wrapping Survey
Message-id: <[e-mail]>
X-User-Info: 210.55.166.93
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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>

Msft versions cannot handle case #1 (I think).

Msft versions can handle case #2 without any problems.

jim schaad

>I have a few questions for implementors.  First some background, then the 

>questions.
>
>The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME

>encodings.  If each of these encodings uses Base64, then the overhead is 
>huge.  I am interested in ways to reduce the overhead, hopefully without 
>hurting IMAP usability.
>
>1.  Can your implementation handle
>	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?
>
>The outer SignedData has the OID for EnvelopedData in the content type, not

>id-data.
>The EnvelopedData has the OID for SignedData in the content type, not id-data.

>The inner Signed Data has the id-data OID in the content type.
>
>2.  Can your implementation handle MIME without Base64 encoding?  I am 
>interested in using "binary" instead of Base64 to reduce the overhead.
>
>Russ
>
>
http://www.nwlink.com


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05059 for ietf-smime-bks; Thu, 9 Mar 2000 08:42:53 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05054 for <[e-mail]>; Thu, 9 Mar 2000 08:42:52 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (rhousley-pc.spyrus.com [207.212.34.221]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA23349 for <[e-mail]>; Thu, 9 Mar 2000 08:43:03 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 09 Mar 2000 11:39:31 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: LAST CALL: draft-ietf-smime-cast-128-01.txt
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>

The CAST-128 algorithm specification is ready for Working Group Last 
Call.  Please post comments to the ietf-smime mail list before 23 March 2000.

Russ

= = = = = = = = = =

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		: Use of the CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-01.txt
	Pages		: 6
	Date		: 03-Mar-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into
the S/MIME Cryptographic Message Syntax (CMS) as an additional
algorithm for symmetric encryption.  The relevant OIDs and processing
steps are provided so that CAST-128 may be included in the CMS
specification [RFC2630] for symmetric content and key encryption.

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

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

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


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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cast-128-01.txt> 


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA26215 for ietf-smime-bks; Thu, 9 Mar 2000 03:29:25 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26203 for <[e-mail]>; Thu, 9 Mar 2000 03:29:23 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25296; Thu, 9 Mar 2000 06:30:08 -0500 (EST)
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-domsec-04.txt
Date: Thu, 09 Mar 2000 06:30:08 -0500
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		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-04.txt
	Pages		: 8
	Date		: 08-Mar-00
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that have internal PKIs
which are not accessible by the outside world, but wish to interoperate
securely using the S/MIME protocol.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-domsec-04.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-domsec-04.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-domsec-04.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25393 for ietf-smime-bks; Tue, 7 Mar 2000 15:26:27 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25389 for <[e-mail]>; Tue, 7 Mar 2000 15:26:26 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29064; Tue, 7 Mar 2000 15:26:53 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 2785 on Methods for Avoiding "Small-Subgroup" Attacks
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 07 Mar 2000 15:26:53 -0800
From: RFC Editor <[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>

--NextPart


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


        RFC 2785

        Title:	    Methods for Avoiding the "Small-Subgroup" Attacks
                    on the Diffie-Hellman Key Agreement Method for
                    S/MIME 
        Author(s):  R. Zuccherato
        Status:     Informational
	Date:       March 2000
        Mailbox:    [e-mail]
        Pages:      11
        Characters: 24415
	Updates/Obsoletes/SeeAlso: None
        I-D Tag:    draft-ietf-smime-small-subgroup-03.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2785.txt


In some circumstances the use of the Diffie-Hellman key agreement
scheme in a prime order subgroup of a large prime p is vulnerable to
certain attacks known as "small-subgroup" attacks.  Methods exist,
however, to prevent these attacks.  This document will describe the
situations relevant to implementations of S/MIME version 3 in which
protection is necessary and the methods that can be used to prevent
these attacks. 

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  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: rfc2785

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

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

--OtherAccess--
--NextPart--


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21856 for ietf-smime-bks; Tue, 7 Mar 2000 12:27:00 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA21852 for <[e-mail]>; Tue, 7 Mar 2000 12:26:59 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Tue, 07 Mar 00 12:27:06 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <FMV7Q9Q2>; Tue, 7 Mar 2000 12:27:06 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Aram Perez'" <[e-mail]>, [e-mail]
Subject: RE: Triple Wrapping Survey
Date: Tue, 7 Mar 2000 12:26:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 14DBB99082655-01-01
Content-Type: text/plain;  charset=iso-8859-1
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>

I think that the point Russ was making is "can you handle nesting of CMS
objects" not "can you handle nesting of MIME wrapped CMS objects".  In our
case, we can only do MIME wrapped CMS objects, but we can handle binary
encoding of those objects.

Blake

-----Original Message-----
From: Aram Perez [mailto:[e-mail]]
Sent: Tuesday, March 07, 2000 6:30 AM
To: [e-mail]
Subject: RE: Triple Wrapping Survey


Hi Russ,

I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, March 06, 2000 7:21 PM
To: [e-mail]
Subject: Triple Wrapping Survey


I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not
id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA15136 for ietf-smime-bks; Tue, 7 Mar 2000 06:29:18 -0800 (PST)
Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15131 for <[e-mail]>; Tue, 7 Mar 2000 06:29:16 -0800 (PST)
Received: by MARS with Internet Mail Service (5.5.2650.21) id <F3J9JYG8>; Tue, 7 Mar 2000 09:29:40 -0500
Message-ID: <D92EE22C97C3D311855E005004E0CBF003362C@MARS>
From: Aram Perez <[e-mail]>
To: [e-mail]
Subject: RE: Triple Wrapping Survey
Date: Tue, 7 Mar 2000 09:29:31 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
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>

Hi Russ,

I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, March 06, 2000 7:21 PM
To: [e-mail]
Subject: Triple Wrapping Survey


I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not
id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10154 for ietf-smime-bks; Mon, 6 Mar 2000 16:21:36 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10150 for <[e-mail]>; Mon, 6 Mar 2000 16:21:35 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (rhousley-pc.spyrus.com [207.212.34.221]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA21276 for <[e-mail]>; Mon, 6 Mar 2000 16:21:37 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 06 Mar 2000 19:21:17 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Triple Wrapping Survey
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 have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27216 for ietf-smime-bks; Mon, 6 Mar 2000 03:56:21 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27212 for <[e-mail]>; Mon, 6 Mar 2000 03:56:19 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02352; Mon, 6 Mar 2000 06:56:49 -0500 (EST)
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-cast-128-01.txt
Date: Mon, 06 Mar 2000 06:56:48 -0500
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		: Use of the CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-01.txt
	Pages		: 6
	Date		: 03-Mar-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into 
the S/MIME Cryptographic Message Syntax (CMS) as an additional  
algorithm for symmetric encryption.  The relevant OIDs and processing 
steps are provided so that CAST-128 may be included in the CMS 
specification [RFC2630] for symmetric content and key encryption.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cast-128-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cast-128-01.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 ns.secondary.com (8.9.3/8.9.3) id JAA04623 for ietf-smime-bks; Fri, 3 Mar 2000 09:56:01 -0800 (PST)
Received: from alpha.it-sec.com (dmz1.itsec.ch [195.141.254.202] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04614 for <[e-mail]>; Fri, 3 Mar 2000 09:55:58 -0800 (PST)
Received: from svzh0004.itsec.ch (localhost [127.0.0.1]) by alpha.it-sec.com (8.9.3/8.9.3) with ESMTP id TAA18455; Fri, 3 Mar 2000 19:54:12 +0100 (MET)
Received: by SVZH0004 with Internet Mail Service (5.5.2448.0) id <1PL1SM5Z>; Fri, 3 Mar 2000 18:53:49 +0100
Message-ID: <F5545CEFBE7CD31190C90004AC4C1B640D267D@SVZH0004>
From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: draft-ietf-smime-idea
Date: Fri, 3 Mar 2000 18:53:48 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"
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>

Firstly, I would like to apologize for the delay of my response (I was busy
on CeBIT).

We highly respect all comments on the draft and would like to proceed in the
following way:

1. we will submit an IPR statement to the IETF and this working group very
soon

2. we will remove all sentences in the draft which could lead to the
impression of marketing; it is not our intention to misuse the draft for
marketing purposes

I would like to remark that the sentence "Organization who make already use
of IDEA for other applications also want to use IDEA in S/MIME." has been
introduced for justification. We sent already an long list of IDEA users in
industry to the SMIME working group (also Mr. Hoffman got this list, and
thus he should not say that he has never heart of anyone wanting to use
IDEA). We can proove that IDEA is widely used in Europe. According to our
experience customers in industry often like to choose a symmetric cipher as
a part of their security policy. This demand should be considered in SMIME,
and that's why we wrote the draft. 

3. The short statement and reference on the security of IDEA has been
introduced in appendix B when Mr. Hoffman asked us to include such a
statement (after submission of draft verion 0). Basically, we reacted on his
doubts about the IDEA security. Anyway, we will remove the statement
"Experts in cryptography consider IDEA to be a highly secure symmetric
cipher [IDEA]" as it can be directly obtained from the stated literature.


Despite different personal opinions about the use of IDEA, we believe, the
customer's desires should be considered. We can proove that big European
companies and banks are using it, and they want to use it in SMIME as well. 

Thanks a lot for your understanding and support.

*Stephan Teiwes, iT_Security AG



-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Mittwoch, 23. Februar 2000 20:20
To: [e-mail]
Subject: Re: draft-ietf-smime-idea


All:

Paul raises some very important points.  Let me share my view as the S/MIME 
Working Group Chair.

1.  We must have an IPR statement for this document to progress to an RFC.

2.  I do not mind some justification text.  Something like: "Organization 
who make already use of IDEA for other applications also want to use IDEA 
in S/MIME."  But, in my opinion, the marketing hype needs to be 
significantly reduced.  The CAST-128 document does not try to convince 
anyone that CAST-128 is appropriate or inappropriate for any particular 
group of users.  The IDEA document should have a similar tone.

3.  I would like this document to become a Standards Track document.  The 
document should state the one and only way that IDEA is used with 
CMS.  Clearly, IDEA will not be mandatory to implement, but if IDEA is 
implemented, then it MUST be done in the manner specified in this 
document.  I cannot recommend that this document become a Standards Track 
RFC until items 1 and 2 are repaired.

Russ


At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
>There are a few things in this document that should raise concern.
>
>Appendix C states clearly that this is a patented algorithm for which 
>licensing is available. However, it appears that no one has let the IETF 
>Secretariat know that. Nothing about IDEA is listed on 
><http://www.ietf.org/ipr.html>. This draft should not be considered until 
>there is a formal statement to the IETF.
>
>Parts of the document sounds like a marketing brochure. "Today, IDEA is 
>widely applied in electronic business applications." "Especially for those 
>organization who make already use of IDEA on a wide scale it is of high 
>interest that IDEA is also available in S/MIME." "Experts in cryptography 
>consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.
>
>These seem particularly inappropriate for an RFC. To be frank, I've never 
>heard of anyone wanting to use IDEA for anything other than old PGP. The 
>folks who wrote PGP had their reasons for choosing IDEA when they did, but 
>they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
>appear to have negatively affected them. The IETF shouldn't codify this 
>kind of marketing hype, even in an Informational RFC. To move forwards 
>with this, it would be nice if the authors went through the draft and took 
>out the marketing fluff.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19548 for ietf-smime-bks; Fri, 3 Mar 2000 06:36:02 -0800 (PST)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19537 for <[e-mail]>; Fri, 3 Mar 2000 06:35:58 -0800 (PST)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-5.05) id ADDC18000FE; Fri, 03 Mar 2000 15:36:12 +0100
Received: from PLIPP2 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0alpha3b 1/December/1999); Fr, 03 Mär 2000 15:36:36 +0100
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Subject: AW: draft-ietf-smime-idea
Date: Fri, 3 Mar 2000 15:36:36 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.90086585--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
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>

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.90086585--
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> In fact, I think there are already FAR too many algorithms,
> variations, etc., in the  S/MIME standard as
> it is, and to virtually no good purpose that I can see.
Yes! As long as there is a strong enough free cipher in there, everybody
should be happy. Maybe another one to choose from, and yes, as AES becomes a
standard, there will be a need to add it(them).

What do the ton's of ciphersuites in TLS buy us if there are major vendors
only supporting the RSA ones and all the products need to be able to talk to
them? Yes, we can say "all ciphersuites implemented in our toolkit"!

Peter
______________________________________
Dr. Peter Lipp
IAIK, TU Graz
Inffeldgasse 16a, A-8010 Graz, Austria
Tel: [phone]
Fax: [phone]
Web: www.iaik.at




----IAIK.SMIME.MAPPER.90086585--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDAzMDMxNDM2MzdaMCMGCSqGSIb3DQEJBDEWBBRHJkBl6UdH6FYn
INN7etKR9xgX4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgKKPYVH9JdFcbH9vNbHCubKRr7wA51fOms0eG4bKjFQT
xozr9nqZRvfXWN9zwPm/pVM2OmXRFoBEGii8Xusbx5BhFtE9BCfI6P1rD7WdKtAT
rBHdzSHWQkqEmQzUjsnOeMX/Siu10VKSdDYnysVr72VMQmfsLsygSzmv3AhsWSFn
AAAAAAAA
----IAIK.SMIME.MAPPER.90086585----