Comments on draft-ietf-smime-cms-rsaes-oaep-01.txt

[<[e-mail]>]

Section 1 Paragraph 4:  Spelling error on interactibe.

Section 2 Paragraph 2: Remove last instance of "[CMS]" as it is not
necessary.

Section 2.1 Paragraph 3: Delete or reword this paragraph as it is not
correct.  originatorInfo may be present due to other recipient infos.

Section 3 Paragraph 5 (maskGenFunc): MFG1 should be changed to MFG1SHA1 or
all references to it using SHA1 should be replaced with references to it
using a OWF.

Section 3 Paragraph 5: Is SHA1 to be the one and only OWF supported here or
are others permitted.  Text is not clear on this issue.

Section 3 Paragaraph 5 and 6:  Why are you requiring that incorrectly
encoded (i.e. the default value is supplied) be recognized? "... recognize
both id-sha1 and absent..."

Section 4 Paragraph 1: Spelling error "SEQUNCEs"

Please add ASN module to the end.  (I am just lazy.)

jim schaad




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA09079 for ietf-smime-bks; Sun, 30 Jul 2000 15:14:36 -0700 (PDT)
Received: from revelation (wireless-132-178.ietf.marconi.com [147.73.132.178]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA09070; Sun, 30 Jul 2000 15:14:32 -0700 (PDT)
Reply-To: <[e-mail]>
From: <[e-mail]>
To: "Russ Housley \(E-mail\)" <[e-mail]>
Cc: "Ietf-Smime \(E-mail\)" <[e-mail]>
Subject: Comments on draft-ietf-smime-cms-rsaes-oaep-01.txt
Date: Sun, 30 Jul 2000 18:02:57 -0400
Message-ID: <000001bffa74$091b7d10$b2844993@revelation>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
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>

Section 1 Paragraph 4:  Spelling error on interactibe.

Section 2 Paragraph 2: Remove last instance of "[CMS]" as it is not
necessary.

Section 2.1 Paragraph 3: Delete or reword this paragraph as it is not
correct.  originatorInfo may be present due to other recipient infos.

Section 3 Paragraph 5 (maskGenFunc): MFG1 should be changed to MFG1SHA1 or
all references to it using SHA1 should be replaced with references to it
using a OWF.

Section 3 Paragraph 5: Is SHA1 to be the one and only OWF supported here or
are others permitted.  Text is not clear on this issue.

Section 3 Paragaraph 5 and 6:  Why are you requiring that incorrectly
encoded (i.e. the default value is supplied) be recognized? "... recognize
both id-sha1 and absent..."

Section 4 Paragraph 1: Spelling error "SEQUNCEs"

Please add ASN module to the end.  (I am just lazy.)

jim schaad



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA11137 for ietf-smime-bks; Thu, 27 Jul 2000 12:56:01 -0700 (PDT)
Received: from mail.babylon.co.il ([194.90.80.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11133 for <[e-mail]>; Thu, 27 Jul 2000 12:55:59 -0700 (PDT)
From: [e-mail]
Received: from fw. ([194.90.80.209]) by mail.babylon.co.il (8.9.3/8.9.3) with SMTP id WAA14455; Thu, 27 Jul 2000 22:09:42 +0300
Received: from [e-mail] by [e-mail] (8.8.5/8.6.5) with SMTP id GAA05569 for <[e-mail]>; Sat, 26 Jun 1999 04:51:25 -0600 (EST)
Date: Sat, 26 Jun 99 04:51:25 EST
To: [e-mail]
Subject: Enter The  I Love/Hate SpamMail Opinion Poll  -Pro Leads 3-1
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Comments: Authenticated sender is <[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>

Hi,
    A Poll is being taken to settle the issue whether 
commercial e-mail or SPAM is a good form of advertisement, 
which you would like more of or it's a bad form of 
advertisement which you are against.

The arguments go more or less as follows:

Pro:
     Commercial E-mail is a very efficient, cost effective means 
of informing people about new goods and services. This translates
into substantial savings to the consumer. That the vast majority 
of internet users don't mind Spam and want to hear about new 
goods and services.  
     That for Years now, more advanced bulk mailing software 
has allowed bulk mailers to shoulder the full cost of Spamming. 
This cost has increased and access has become much more difficult 
due to unfair and illegal practices by the big providers (the 
later day Robber Barons) Who have a vested interest in keeping 
Costs and Profits high for as long as possible, and with the news 
media with whom most have formed alliances, have and continue 
to wage a war of misinformation, deceptions, and out and out lies.  
     That through an unholy alliance with vix.com, individuals 
and companies have been targeted by cyber terrorists who have 
attacked their equipment, programming and subjected people to 
threats of violence by posting personal information on these 
legitimate companies employees and individuals home addresses, 
phone numbers, which leads to threats against them, there 
families and children.  
     Lastly, that the Robber Barons (Big Internet Providers) use 
special identification programs in their efforts to stop free 
trade that invades the privacy of all individuals by identifying, 
reading, and then determining whether or not you will get your 
mail or not (ask yourself this question, if AOL or SPRINT or AT&T 
or MicroSoftNetwork, (MSN), sent someone to your house to 
intercept your mail, open it, read it, and then arbitrarily 
decide whether they will put it in your mail box or not. Would 
you put up with that?)  They call it filtering, we know it by 
its more insidious name, CENSORSHIP.  

Why in the world should you be subjected to this, and have to pay 
higher prices !  



Anti SPAM:

     Anti Spam arguments go something like this:
They don't like it.  
     Some genuinely want to be isolated fromthe world, others it 
seems are simply being mislead.   Spammers steal services and 
don't really pay for access, Spammers are evil because the big, 
rich, powerful, largeinternet service providers say so, and it's 
OK to targetthem for all kinds of bad things, legal or not.  
They don't like it. 
     And would rather have themselves and consumers everywhere 
continue to pay high inflated pricesso that the Robber Barons 
may grow even richer and morepowerful.  
     And finally, much like the Nazi's final solution to the 
Jewish problem, they are willing to act as the RobberBaron's 
Gestapo, ready to report for termination any Spammers or Spam 
sympathizers.  

SIMPLE SOLUTION: Press the delete key, STUPID !
    


  
       
Have a different opinion, give us a call because, your 
opinion on how to make this kind of advertisement better & 
to increase its use, is vital. Or if this is a terrible 
form of advertisement and how it should be curtailed, 
regulated or ended all together.


    Please call, 1-900-226-0388 and tell us.



   The charges for registering your opinion are as follows:
Of the $1.99 per minute charge, 
1-dollar goes to the telephone service Bureau 
19 cents to retrieve your opinion
79 cents to transcribe this information into a viable format
Leaving a total of 2 cents.
   So do call if you wish to get your 2 cents worth in !





Attention both Pro and Anti Spam Advocates and those of you who 
may have sought removal from any number of bulk mailing lists.  
If you have received this e-mail it is because it is a conscious 
decision on our part to try and include everyone in this important 
poll. To not have included those who profess a dislike for this 
form of advertisement would have eliminated those individuals 
from the process and provide an unfair advantage to one side of 
the poll. We sincerely hope that all interested individuals or 
entity's understand the necessity of inclusion.


 ******************************************************** 

 This message is sent in compliance of the proposed 
 bill: SECTION 301. 
 Per Section 301, Paragraph (a)(2)(C) of S. 1618, 
 further transmissions to you by the sender of this 
 email may be stopped at no cost to you by sending a 
 reply to this email address with the word remove in 
 the subject line. This message is not intended for 
 residents in the State of Washington, screening of 
 addresses has been done to the best of our technical 
 ability. If you are a Washington, Virginia, or 
 California resident or otherwise wish to be removed 
 from this list, further transmissions to you by the 
 sender of this email may be stopped at no cost to you 
 by sending a reply to   [e-mail] 
 with the word remove in the subject line. 

 ********************************************************* 




11-a-54



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA26723 for ietf-smime-bks; Wed, 26 Jul 2000 11:59:15 -0700 (PDT)
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26719 for <[e-mail]>; Wed, 26 Jul 2000 11:59:14 -0700 (PDT)
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 MAA07199; Wed, 26 Jul 2000 12:02:42 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <PT6DXXZM>; Wed, 26 Jul 2000 12:01:19 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Baumgart, Ralf'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Some Questions to S/MIME
Date: Wed, 26 Jul 2000 12:01:19 -0700
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_0000_01BFF712.86137F80"; 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_0000_01BFF712.86137F80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The delay is not unusual and is a consequence of the IETF process and
the IETF principle that standards should describe actual practice and
implementation.

Unlike other standards bodies, the IETF requires that implementations be
deployed before recognizing a protocol as a 'standard'. Thus an IETF
protocol typically becomes a standard some years AFTER it has been in
common use. In the case of HTTP (the Web) this process took seven years.

In other standards bodies development only starts after the standard has
been fully agreed and approved. This approach is not a very good one
since it is almost always desirable to modify the specification in the
light of implementation experience.


In essence the IETF approach is more like the Noble prizes, you get one
after everyone has agreed that you have done the work and established a
standard. The other body appears to regard agreement of standard as if
it were the award of a building permit.


The next significant event in the S/MIME standards track progress will
be the promotion to Draft status. This is a highly technical process
that involves a lot of input from implementors of the protocol. Before
this can take place however all the standards that S/MIME references
must also progress to draft standard status.

In the meantime products based on the S/MIME v3 protocol and designed to
interoperate with it are already available. In that sense S/MIME is
quite clearly a 'standard' as the IETF defines it. Unfortunately it will
take a while for the paperwork to catch up.

		Phill


-----Original Message-----
From: Baumgart, Ralf [mailto:[e-mail]]
Sent: Wednesday, July 26, 2000 7:41 AM
To: '[e-mail]'
Subject: Some Questions to S/MIME



Dear sirs,

the Commerzbank, a big bank in Germany, is evaluating S/MIME. We were
astonished that S/MIME V.3 became a proposed standard in July 1999. Now
one
year later nothing happens (on your imc-Web Sites). So our questions is,
what could happened in the next six months: Will the proposed standard
become a standard? What avtivities are proposed? 

with best regards
ralf baumgart
Commerzbank AG
Abteilung ZIT P 3.53 Email/Web
60261 Frankfurt/Main
Tel.:[phone]
email: ralf.baumgart@commee

------=_NextPart_000_0000_01BFF712.86137F80
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
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcyNjE5MDIzMlowIwYJKoZI
hvcNAQkEMRYEFJXcE1gSFQQ3pxGX7szVUJa9hr3UMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAScO58s1AZ0GjB+q/Gf1p7f3Skyf3oE6VrQKojesdkDdri6p7NedxT9lWlZ56kVku
gMRoDk57VqcQy0GPDEBIvGUPbq7l7IEKje0FG3K3LUKR/3acErSjtPv05/BTpeh2rJ48mqXsJ2aA
OQJq90UEkcQzNcQRJIftuC7aogVlJFQAAAAAAAA=

------=_NextPart_000_0000_01BFF712.86137F80--



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06227 for ietf-smime-bks; Wed, 26 Jul 2000 07:25:41 -0700 (PDT)
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 HAA06223 for <[e-mail]>; Wed, 26 Jul 2000 07:25:40 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA00552; Wed, 26 Jul 2000 07:27:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 26 Jul 2000 10:12:55 -0400
To: "Baumgart, Ralf" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Some Questions to S/MIME
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <6F539391E018D3119B570008C75D91E8BFB6D0@SV018442>
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>

Ralf:

I strongly disagree with your assessment.  Important things are happening, 
perhaps not as quickly as we would all like, but they are happening.  Most 
importantly, vendors are implementing!  Major vendors have S/MIME products.

Russ


At 01:41 PM 07/26/2000 +0200, Baumgart, Ralf wrote:

>Dear sirs,
>
>the Commerzbank, a big bank in Germany, is evaluating S/MIME. We were
>astonished that S/MIME V.3 became a proposed standard in July 1999. Now one
>year later nothing happens (on your imc-Web Sites). So our questions is,
>what could happened in the next six months: Will the proposed standard
>become a standard? What avtivities are proposed?
>
>with best regards
>ralf baumgart
>Commerzbank AG
>Abteilung ZIT P 3.53 Email/Web
>60261 Frankfurt/Main
>Tel.:[phone]
>email: ralf.baumgart@commee



Received: by ns.secondary.com (8.9.3/8.9.3) id EAA27142 for ietf-smime-bks; Wed, 26 Jul 2000 04:38:59 -0700 (PDT)
Received: from mail1.commerzbank.com (mail1.commerzbank.com [193.158.252.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27138 for <[e-mail]>; Wed, 26 Jul 2000 04:38:57 -0700 (PDT)
Received: from sv004404.zdv.commerzbank.com (sv004404.cbkinternal.com [140.100.200.104]) by mail1.commerzbank.com (Postfix) with ESMTP id 64979156D70 for <[e-mail]>; Wed, 26 Jul 2000 13:41:31 +0200 (CEST)
Received: from sv016317.exchange.commerzbank.com (sv016317.exchange.commerzbank.com [140.100.200.214]) by sv004404.zdv.commerzbank.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA14014 for <[e-mail]>; Wed, 26 Jul 2000 13:41:32 +0200 (METDST)
Received: by SV016317 with Internet Mail Service (5.5.2448.0) id <P4XSWZ6M>; Wed, 26 Jul 2000 13:41:23 +0200
Message-ID: <6F539391E018D3119B570008C75D91E8BFB6D0@SV018442>
From: "Baumgart, Ralf" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Some Questions to S/MIME
Date: Wed, 26 Jul 2000 13:41:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
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>

Dear sirs,

the Commerzbank, a big bank in Germany, is evaluating S/MIME. We were
astonished that S/MIME V.3 became a proposed standard in July 1999. Now one
year later nothing happens (on your imc-Web Sites). So our questions is,
what could happened in the next six months: Will the proposed standard
become a standard? What avtivities are proposed? 

with best regards
ralf baumgart
Commerzbank AG
Abteilung ZIT P 3.53 Email/Web
60261 Frankfurt/Main
Tel.:[phone]
email: ralf.baumgart@commee



Received: by ns.secondary.com (8.9.3/8.9.3) id RAA17195 for ietf-smime-bks; Tue, 25 Jul 2000 17:34:42 -0700 (PDT)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17191 for <[e-mail]>; Tue, 25 Jul 2000 17:34:41 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0432040ab5a3e2c45c4f@[165.227.249.17]>
Date: Tue, 25 Jul 2000 17:37:44 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: On requiring RSA (after September 20th, of course)
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>

Blake Ramsdell has turned in two drafts that are worthy of 
consideration in this group. It's my opinion that they represent the 
reality of the marketplace, and that it would be good to have our 
RFCs reflect that if possible.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>	Title		: S/MIME Version 3.1 Certificate Profile Addendum
>	Author(s)	: B. Ramsdell
>	Filename	: draft-ramsdell-smime31-cert-00.txt
>	Pages		:
>	Date		: 24-Jul-00
>
>In light of the expiration of the primary RSA patent, it is proposed
>that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
>implement algorithms in the S/MIME profile. This draft will describe
>only the proposed changes to the S/MIME Version 3 Certificate Handling
>RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ramsdell-smime31-cert-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-ramsdell-smime31-cert-00.txt".


>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>	Title		: S/MIME Version 3.1 Message Specification Addendum
>	Author(s)	: B. Ramsdell
>	Filename	: draft-ramsdell-smime31-msg-00.txt
>	Pages		:
>	Date		: 24-Jul-00
>
>In light of the expiration of the primary RSA patent, it is proposed
>that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
>implement algorithms in the S/MIME profile. This draft will describe
>only the proposed changes to the S/MIME Version 3 Message
>Specification RFC [SMIMEV3MSG], and the rest of that RFC will remain
>identical.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ramsdell-smime31-msg-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-ramsdell-smime31-msg-00.txt".

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA08621 for ietf-smime-bks; Tue, 25 Jul 2000 03:35:27 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08611 for <[e-mail]>; Tue, 25 Jul 2000 03:35:26 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24788; Tue, 25 Jul 2000 06:38:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-ecc-01.txt
Date: Tue, 25 Jul 2000 06:38:25 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Elliptic Curve S/MIME
	Author(s)	: D. Brown
	Filename	: draft-ietf-smime-ecc-01.txt
	Pages		: 20
	Date		: 24-Jul-00
	
This document is the second draft of a profile for the
   incorporation of Elliptic Curve Cryptography (ECC) public key
   algorithms in the Cryptographic Message Syntax (CMS).  The ECC
   algorithms support the creation of digital signatures and the
   exchange of keys to encrypt or authenticate message content.  The
   definition of the algorithm processing is based on the ANSI X9.62
   standard and the ANSI X9.63 draft, developed by the ANSI X9F1
   working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-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-ecc-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-ecc-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-ecc-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ecc-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 NAA20223 for ietf-smime-bks; Mon, 24 Jul 2000 13:10:52 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20219 for <[e-mail]>; Mon, 24 Jul 2000 13:10:50 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA05169; Mon, 24 Jul 2000 13:13:48 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA05145; Mon, 24 Jul 2000 13:13:48 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA12565; Mon, 24 Jul 2000 13:14:22 -0700 (PDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20180 for ietf-smime-bks; Mon, 24 Jul 2000 13:09:04 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20176 for <[e-mail]>; Mon, 24 Jul 2000 13:09:03 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA01435; Mon, 24 Jul 2000 13:12:01 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA01420; Mon, 24 Jul 2000 13:12:00 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA11729; Mon, 24 Jul 2000 13:12:34 -0700 (PDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20143 for ietf-smime-bks; Mon, 24 Jul 2000 13:07:17 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20139 for <[e-mail]>; Mon, 24 Jul 2000 13:07:16 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA27660; Mon, 24 Jul 2000 13:10:11 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA27652; Mon, 24 Jul 2000 13:10:10 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA11048; Mon, 24 Jul 2000 13:10:45 -0700 (PDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for <[e-mail]>; Mon, 24 Jul 2000 12:59:11 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com  with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for [e-mail]; Mon, 24 Jul 2000 15:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for <[e-mail]>; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt
Date: Mon, 24 Jul 2000 06:38:44 -0400
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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		: S/MIME Symmetric Key Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-01.txt
	Pages		: 55
	Date		: 21-Jul-00
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-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-symkeydist-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-symkeydist-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-symkeydist-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-symkeydist-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 NAA20180 for ietf-smime-bks; Mon, 24 Jul 2000 13:09:04 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20176 for <[e-mail]>; Mon, 24 Jul 2000 13:09:03 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA01435; Mon, 24 Jul 2000 13:12:01 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA01420; Mon, 24 Jul 2000 13:12:00 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA11729; Mon, 24 Jul 2000 13:12:34 -0700 (PDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA20143 for ietf-smime-bks; Mon, 24 Jul 2000 13:07:17 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20139 for <[e-mail]>; Mon, 24 Jul 2000 13:07:16 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA27660; Mon, 24 Jul 2000 13:10:11 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA27652; Mon, 24 Jul 2000 13:10:10 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA11048; Mon, 24 Jul 2000 13:10:45 -0700 (PDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for <[e-mail]>; Mon, 24 Jul 2000 12:59:11 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com  with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for [e-mail]; Mon, 24 Jul 2000 15:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for <[e-mail]>; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt
Date: Mon, 24 Jul 2000 06:38:44 -0400
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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		: S/MIME Symmetric Key Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-01.txt
	Pages		: 55
	Date		: 21-Jul-00
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-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-symkeydist-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-symkeydist-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-symkeydist-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-symkeydist-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 NAA20143 for ietf-smime-bks; Mon, 24 Jul 2000 13:07:17 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20139 for <[e-mail]>; Mon, 24 Jul 2000 13:07:16 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA27660; Mon, 24 Jul 2000 13:10:11 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA27652; Mon, 24 Jul 2000 13:10:10 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA11048; Mon, 24 Jul 2000 13:10:45 -0700 (PDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for <[e-mail]>; Mon, 24 Jul 2000 12:59:11 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com  with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for [e-mail]; Mon, 24 Jul 2000 15:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for <[e-mail]>; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt
Date: Mon, 24 Jul 2000 06:38:44 -0400
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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		: S/MIME Symmetric Key Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-01.txt
	Pages		: 55
	Date		: 21-Jul-00
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-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-symkeydist-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-symkeydist-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-symkeydist-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-symkeydist-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 MAA19973 for ietf-smime-bks; Mon, 24 Jul 2000 12:59:13 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19969 for <[e-mail]>; Mon, 24 Jul 2000 12:59:11 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA11643; Mon, 24 Jul 2000 13:02:09 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA11614; Mon, 24 Jul 2000 13:02:08 -0700 (PDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by qualcomm.com  with ESMTP id NAA07955; Mon, 24 Jul 2000 13:02:41 -0700 (PDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21703 for [e-mail]; Mon, 24 Jul 2000 15:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16241 for <[e-mail]>; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09375; Mon, 24 Jul 2000 06:38:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-01.txt
Date: Mon, 24 Jul 2000 06:38:44 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Symmetric Key Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-01.txt
	Pages		: 55
	Date		: 21-Jul-00
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-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-symkeydist-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-symkeydist-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-symkeydist-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-symkeydist-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 DAA23945 for ietf-smime-bks; Wed, 19 Jul 2000 03:33:14 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23940 for <[e-mail]>; Wed, 19 Jul 2000 03:33:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21606; Wed, 19 Jul 2000 06:35:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-espolicies-00.txt
Date: Wed, 19 Jul 2000 06:35:43 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Electronic Signature Policies
	Author(s)	: J. Ross, D. Pinkas, N. Pope
	Filename	: draft-ietf-smime-espolicies-00.txt
	Pages		: 42
	Date		: 18-Jul-00
	
This RFC defines signature policies for electronic signatures. 
A signature policy is a set of rules for the creation and validation 
of an electronic signature, under which the validity of signature can 
be determined. A given legal/contractual context may recognize a 
particular signature policy as meeting its requirements. 

A signature policy has a globally unique reference, which is bound to 
an electronic signature by the signer as part of the signature 
calculation.

The signature policy needs to be available in human readable form so 
that it can be assessed to meet the requirements of the legal and 
contractual context in which it is being applied.

To allow for the automatic processing of an electronic signature 
another part of the signature policy specifies the electronic 
rules for the creation and validation of the electronic signature in 
a computer processable form.  In the current document the format of the 
signature policy is defined using ASN.1. 

The contents of this RFC is based on the signature policy defined in
ETSI ES 201 733 V.1.1.3(2000-05) Copyright (C).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-espolicies-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-espolicies-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-espolicies-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-espolicies-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-espolicies-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 LAA02245 for ietf-smime-bks; Sat, 15 Jul 2000 11:48:22 -0700 (PDT)
Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02241 for <[e-mail]>; Sat, 15 Jul 2000 11:48:21 -0700 (PDT)
Received: from 207-172-49-64.s64.tnt7.lnhva.md.dialup.rcn.com ([207.172.49.64] helo=rhousley_laptop) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13DX1F-0007Yf-00; Sat, 15 Jul 2000 14:50:33 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 15 Jul 2000 14:02:27 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: DRAFT S/MIME WG Aganda
Cc: [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>

Here is the DRAFT agenda for the S/MIME WG on 31 July 2000.

Russ

= = = = = = = = =

* Introductions				Russ Housley
* Working Group Status		Russ Housley
* CMS/ESS Examples			Paul Hoffman
* Interoperability Matrix 		Jim Schaad
* CERTDIST Draft Discussion 		Jim Schaad
* Security Policies and Labels		Weston Nicolls
* Symmetric Key Distribution		Sean Turner
* DOMSEC Draft Discussion 		Bill Ottaway
* Electronic Signature Formats		Denis Pinkas
* Signature Policy Format		Denis Pinkas
* Wrap up				Russ Housley


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA14955 for ietf-smime-bks; Fri, 14 Jul 2000 14:03:22 -0700 (PDT)
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 OAA14951; Fri, 14 Jul 2000 14:03:21 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <3GNFB431>; Fri, 14 Jul 2000 17:04:54 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.7 S/MIME Freeware Library Now Available
Date: Fri, 14 Jul 2000 17:04:47 -0400
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>

All,

Wang Government Services, Inc. (WGSI), A Getronics Company, has delivered
Version 1.7 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>.  

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 v1.3 Enhanced SNACC

ASN.1 Library to encode/decode objects. The v1.7 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); 
v1.3 Enhanced SNACC 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 used the SFL to successfully process all of the 
SFL-supported sample data included in the S/MIME WG "Examples of S/MIME
Messages"
document.  We have also performed limited S/MIME v3 testing with Baltimore
and
Entrust.  

The following enhancements are included in the v1.7 SFL release (compared
with 
the v1.6 release):

1) Tested using new, consolidated SNACC library and other common libraries
shared with the v1.3 Access Control Library (ACL) and v1.71 Certificate
Management Library (CML).

2) Re-configured directory structure for SFL source code files so that it is
consistent with the ACL and CML.  

3) Corrected bugs in SPEX/ CTIL.  Successfully used SPEX/ CTIL to provide
RSA key management and DES using the Spyrus SPEX/ Library v1.52b Release 7b,
Spyrus Lynks Card and X.509 v3 Certificates created by the Spyrus S2CA.  We
also tested SHA1-with-RSA signature creation/verification using the Lynks
Card.  We also tested the Fortezza algorithm suite using a Fortezza Card.  

4) Corrected several bugs reported by customers.

5) 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; enhancing CertificateBuilder to support creation of Attribute 
Certificates; modify PKCS #12 code in test utilities to provide
interoperable key 
storage; add MIME support for test drivers; 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) snacc13rn.tar.gz: Zip file containing v1.3 Enhanced SNACC ASN.1 Compiler
and 
Library source code compilable for Unix and MS Windows NT/95/98/2000 that
has been 
enhanced by WGSI 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) smimeR1.7.tar.gz:  Zip file containing all SFL source code including: 
SFL Hi-Level source code; 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/2000. MS Windows NT/95/98/2000
project files and Unix makefiles are included for the SNACC code and
Crypto++.    

4) smCTIR1.7.tar.gz:  Source code for the following CTILs: Test (no crypto),

Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11.  The Win95/98/NT/2000
projects are 
also included.  (NOTE: The Free (a.k.a. Crypto++) CTIL includes
WGSI-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 WGSI-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.  WGSI 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 Fortezza Developer's S/MIME Page.

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 not password controlled.

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

All comments regarding the SFL source code and documents are welcome.  This
SFL release announcement was sent to several mail lists, but please send all
messages regarding the SFL to the imc-sfl mail list ONLY.  Please do not
send messages regarding the SFL to any of the IETF mail lists.  We will
respond to all messages sent to the imc-sfl mail list.

============================================
John Pawling, [e-mail]
Wang Government Services, Inc.,
A Getronics Company
============================================ 


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16177 for ietf-smime-bks; Fri, 14 Jul 2000 03:54:46 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16173 for <[e-mail]>; Fri, 14 Jul 2000 03:54:44 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10841; Fri, 14 Jul 2000 06:56:49 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-esformats-01.txt
Date: Fri, 14 Jul 2000 06:56:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Electronic Signature Formats for long term electronic 
                          signature
	Author(s)	: D. Pinkas, J. Ross, N. Pope
	Filename	: draft-ietf-smime-esformats-01.txt
	Pages		: 75
	Date		: 13-Jul-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 (i.e. repudiates, see [ISONR]) the validity of the signature.
The format can be considered as an extension to RFC 2630 [CMS] and RFC 
2634 [ESS], where, when appropriate additional signed and unsigned 
attributes have been defined.
The contents of this Informational RFC is technically equivalent to 
ETSI ES 201 733 V.1.1.3 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-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-esformats-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-esformats-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-esformats-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-esformats-01.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 GAA23527 for ietf-smime-bks; Thu, 13 Jul 2000 06:05:11 -0700 (PDT)
Received: from sol.fem.com.br ([200.202.236.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23520 for <[e-mail]>; Thu, 13 Jul 2000 06:05:08 -0700 (PDT)
Received: from djdswk ([209.206.0.87]) by sol.fem.com.br (Netscape Messaging Server 3.6)  with ESMTP id AAA2DB1; Thu, 13 Jul 2000 10:00:37 -0300
From: "Nora grenberg" <[e-mail]>
Subject: You First... #6038
To: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 4.0 (32)
Mime-Version: 1.0
Date: Thu, 13 Jul 2000 05:47:19 -0500
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA23524
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>

FREE E-COMMERCE WHEN YOU HOST WITH US!!

Tired of expensive e-commerce software, set up fees and leasing
contracts?
Here is the deal: Sign up for our E-Commerce Package and get a free
merchant account + a $200 cash coupon.

WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS
LESS
DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS.
DON'T
MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE!

While others charge you hundreds of dollars to get a merchant account
or
put you on a 48 months non-cancelable lease agreement we charge you
NOTHING for your merchant account when you sign up for one of our e
-commerce hosting plans. If you wish to stay with your current
hosting company or have already a merchant account our offer is even
better. We have 7 different E-Commerce plans to suit your individual
needs. We have a solution for U.S. beased merchants and international
merchants. Wherever you are on this planet, we get your online store
up and running within a few days.

Check it out first and make an informed decision. You have never seen
a
package deal like this before:

* Your own merchant account with one of the lowest rates in the
industry
* Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS
,
DINERSCLUB/CARTE BLANCHE, JCB
* Direct deposit within 48 hrs into your checking account
* Shopping Cart store front software with an easy to use web based
interface
* Real-Time Credit Card Processing software
* Virtual terminal for phone/fax/mail orders
* Automated E-mail receipts to your clients
* Recurring billing feature with batch uploads
* Automatic batch closing
* Address verification system (AVS)
* Back office to 24/7 access account history
* 75 MB (megabytes) of disk space
* 30 GB (gigabyte) of data transfer per month
* 25 POP3 E-mail accounts
* Unlimited alias E-mail addresses
* Live web site statistics
* Unlimited FTP uploads
* Anonymous FTP
* CGI directory for your own scripts
* Site control panel
* Installation included
* Tech support included

All this and more when you sign up for our E-Commerce Hosting plan
for ONLY $69.95 per month and a one time set up fee of $199.00.  That
's right. NO ADDITIONAL SET UP FEES or application fees for your
merchant account,
real-time software or shopping cart storefront. A one-stop E-Commerce
solution. And the best is:

NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME.

In addition you get a FREE listing in our mall and FREE advertising
to
promote your store. We drive traffic to your site and help you to
become a
successful .com business.

REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS
SPECIAL
OFFER IS ONLY GOOD FOR 7 DAYS!

Please reply to:

mailto:[e-mail]?subject=INFO-PLEASE 
to receive our FREE e-mail
information package without obligations.

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





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA15793 for ietf-smime-bks; Thu, 13 Jul 2000 03:27:23 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15789 for <[e-mail]>; Thu, 13 Jul 2000 03:27:21 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11455; Thu, 13 Jul 2000 06:29:21 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-domsec-06.txt
Date: Thu, 13 Jul 2000 06:29:21 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-06.txt
	Pages		: 8
	Date		: 12-Jul-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 series and SMTP/MIME, or when a
single domain wishes to communicate securely with one of its members
residing on an untrusted domain. The scenarios covered by this document
are domain to domain, individual to domain and domain to individual
communications. 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-06.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-06.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-06.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-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-domsec-06.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 RAA06895 for ietf-smime-bks; Wed, 12 Jul 2000 17:13:13 -0700 (PDT)
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 RAA06891 for <[e-mail]>; Wed, 12 Jul 2000 17:13:11 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA13974; Wed, 12 Jul 2000 17:15:08 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 2876 on KEA and SKIPJACK Algorithms in CMS
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Jul 2000 17:15:08 -0700
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 2876

        Title:	    Use of the KEA and SKIPJACK Algorithms in CMS 
        Author(s):  J. Pawling
        Status:     Informational
	Date:       July 2000
        Mailbox:    [e-mail]
        Pages:      13
        Characters: 29265
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-cmskea-05.txt

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


This document describes the conventions for using the Key Exchange
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with
the Cryptographic Message Syntax [CMS] enveloped-data and
encrypted-data content types.

This document is the 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: rfc2876

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

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 CAA17993 for ietf-smime-bks; Mon, 10 Jul 2000 02:41:45 -0700 (PDT)
Received: from citicorp.com (mango2.citicorp.com [192.193.195.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17989 for <[e-mail]>; Mon, 10 Jul 2000 02:41:44 -0700 (PDT)
From: [e-mail]
Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.195.186]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA00913; Mon, 10 Jul 2000 05:39:53 -0400 (EDT)
Received: from x400prod2.cgin.us-md.citicorp.com ([e-mail] [163.39.249.91]) by myrtle1.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27625; Mon, 10 Jul 2000 05:42:53 -0400 (EDT)
Received: from mercury.lew.gb.citicorp.com (mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA13850; Mon, 10 Jul 2000 05:42:52 -0400 (EDT)
Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02917; Mon, 10 Jul 2000 10:44:47 +0100 (BST)
X-OpenMail-Hops: 1
Date: Mon, 10 Jul 2000 10:44:37 +0100
Message-Id: <H000038a065317ab@MHS>
Subject: RE: RE: Canonicalisation of embedded MIME objects
MIME-Version: 1.0
TO: [e-mail]
CC: [e-mail]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
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>

Ahmed,
 thanks for your reply. The canonicalisation I refer to is defined in RFC45 
section 6.6 page 19 and more specifically again in RFC2049 section 4 subsection 
2 second paragraph page 10. It states:

"For example in the case of text/plain data, the text must be converted to a 
supported character set and lines must be delimited with CRLF delimiters in 
accordance with RFC 822..."


It is my interpretation that ALL embedded objects must have valid <CRLF> line 
ends on their MIME headers. ALL body parts, except binary, must also have valid 
<CRLF> line ends. Just as the outer MIME message has.

Your comments will be very much appreciated.

Regards,
Bartley.
-----Original Message-----
From: zahid.ahmed [SMTP:[e-mail]]
Sent: Saturday, July 08, 2000 1:45 AM
To: bartley.omalley
Cc: zahid.ahmed
Subject: RE: Canonicalisation of embedded MIME objects

can you define what you mean by Canonicalisation of multipart mime?
What specific requirements and assumption you have?

thanks,
Zahid Ahmed


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> Sent: Friday, July 07, 2000 2:57 AM
> To: [e-mail]
> Subject: FW: Canonicalisation of embedded MIME objects
> 
> 
> I posted this earlier but got only one response and no help.
> 
> Can anyone help or point me in the right direction where I may find 
> clarification.
> 
> I am aware that the standards say "be modest in what you send 
> and generous in 
> what you accept" but It seems that a significant number of 
> people/implementers 
> are not following the standard as defined.
> 
> Bartley.
> 
> -----Original Message-----
> From: O'Malley, Bartley 
> Sent: Friday, June 23, 2000 1:03 PM
> To: 'ietf-smime'
> Subject: Canonicalisation of embedded MIME objects
> 
> I have noticed that a number of files as produced by 
> different mail programs do 
> not seem to be performing canonicalisation of inner objects correctly.
> 
> The inner objects use LF for line termination not CRLF pairs. 
> It is my 
> understanding that breaks MIME rules for canonicalising 
> embedded objects.
> 
> To illustrate the problem I enclose a signed-then-encrypted 
> message I have 
> received:(I have removed the routing information)
> 
> The outer message appears as follows(All lines are terminated 
> with <CRLF> 
> pairs.).
> -----------------------------------------------------------
> Content-Type: application/pkcs7-mime; 
> smime-type=encrypted-data;                
>               name="xxx.p7m"                                  
>                   
> Content-Disposition: attachment; filename=xxx.p7m             
>                   
> Content-Transfer-Encoding: base64                             
>                   
> Message-ID: 19991015:080159:REF12345                          
>                   
>                                                               
>                   
> MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1
> UEBhMCVVMx        
> ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW
> 50IDICBDUa
> :
> :        
> VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC
> 4RdXrwyH2l        
> 1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WY
> Eo+aKglqhJ        
> --------------------------------------------------------------
> ------------------
> ----
> 
> 
> The embedded message looks as follows(All lines are 
> terminated with <LF>).
> 
> --------------------------------------------------------------
> --------------
> Content-Type: application/pkcs7-mime; smime-type=signed-data;
>               name="xxx.p7m"
> Content-Disposition: attachment; filename=xxx.p7m
> Content-Transfer-Encoding: base64
> Message-ID: 19990225:131734:20499
> 
> MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKo
> ZIhvcNAQcB
> :
> :
> mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSl
> vuG6deAhgZ
> XJ0KskSW4qT5
> --------------------------------------------------------------
> ---------------
> 
> 
> The inner application file looks as follows: With Content 
> lines terminated with 
> <LF> and the data segment with no line ends.
> 
> --------------------------------------------------------------
> --------------
> Content-Type: application/EDIFACT;
>               name="xxx.edi"
> Content-Transfer-Encoding: binary
> 
> UNA:+.? 'UNB+UNOA:1+
> 
> 
> 
> --------------------------------------------------------------
> ---------------
> 
> 
> It is my interpretation that the use of <LF> to terminate the 
> Content headers 
> in the latter two messages above is not valid.
> 
> Can someone provide me with a definitive answer.
> 
> Thanks,
> Bartley.
> 
> 
> 
> 
> 




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23831 for ietf-smime-bks; Fri, 7 Jul 2000 09:52:30 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23827 for <[e-mail]>; Fri, 7 Jul 2000 09:52:29 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id MAA20865; Fri, 7 Jul 2000 12:53:51 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 07 Jul 2000 12:52:01 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: SMIME cert dist draft and X.509
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>

Jim and Sharon,

The biggest concern I have is the duplication of certificates in directory and
finding certification path.  The CertificateSet, which is required to be present
in SMimeCertificatePublish object, is a set of certificates that MUST be
present.  It contains a "bucket-o-certs" for the user certificates and CA
certificates.  If we could replace it with a pointer to the user certificate and
CA certificates it would solve this duplication problem. PKIPath couldn't be
used because it too is not a pointer.  Could we use something like (hack my
ASN.1 as you please) the following instead of CertificateSet:

CertificatesForSMIME ::= SEQUENCE {
  sMIMEUserCertificate CertificateIdentifier,
  sMIMECACertificates  SEQUENCE OF CertificateIdentifier }

CertificateIdentifier ::= CHOICE {
  issuerAndSerialNumber     IssuerAndSerialNumber,
  subjectKeyIdentifier  [0] SubjectKeyIdentifier }

This would solve the problem of duplication and it would provide the certificate
path.  This won't solve the problem of backwards compatibility though.  So maybe
we could use the following instead of CertificateSet too:

CertificateForSMIME ::= CHOICE {
  actualCertificates    CertificateSet,
  -- For backward compatibility with Netscape and Microsoft code
  pointerToCertficates  CertificatesForSMIME }

Thoughts?

Other issues:

- Using SMIMECapabilities instead of supportAlgorithms

To be honest I don't have a preference.  supportAlgorithms is in X.500 but
SMIMECapabilities is in an RFC.  Both are implemented.

- Using attribute certificates to bind algorithm instead of SMIMECapabilities

I think while it should  be a goal to use attribute certificates to bind the
algorithms to the certificates I don't think we're there yet (some maybe but not
most).  We probably don't want to wait for everbody to implement attribute
certificates before implementing this mechanism.

Cheers,

spt

Jim Schaad wrote:

> Sharon,
>
> There were a number of limitations that are in X509 that I was trying to
> overcome with this draft:
>
> The supportedAlgorithms field was not used for two reasons, first I did not
> know about it when this started and secondly attribute certificates were not
> defined at the time the problem was addressed, thus they were not a part of
> every S/MIME application already.  The use of the SignedData structure means
> that we are re-using already existing code in every S/MIME application.
> (The exact same mechinism is used for transfering the information when
> sending a signed message between two entities.)
>
> Given that we are living in an LDAP world rather than an X509 world, using
> isser DNs of certificates to attempt to find an issuer certificate is an
> extremely difficult problem.  Add to this the questions of
> companies/individuals not publishing intermeadiate CA certificates or making
> them private (although the CRL might be available from a non-directory
> location) and I don't know that in the internet world that the certificate
> retrevial portion of path construction is viable.
>
> While I agree that this problem might have been better considered in the
> PKIX working group as the problem is universion, however the problem and the
> solution was first found by S/MIME developers and the chair of the group
> agreed that it was a reasonable problem to be put before the group.
> Additionally, the solution used some items that were defined by the working
> group in the S/MIME documents rather than in PKIX documents.  Lastly, the
> PKIX group is still very X509 directory centric in many of it's solutions
> while the S/MIME working group is extremely LDAP centric.  Thus what seems
> to be a problem for the S/MIME working group might not be a problem for the
> PKIX working group (such as finding CA certificates without an X509
> directory).
>
> Additionally please note that we have not solved the general path
> construction problem, we have only made it easier (since the holder of the
> certificate is in a better situation to build their own path) for the sender
> to avoid the problem.  In the event that the PKIX group came up with a
> viable method of doing path discovery then this draft can be revised so that
> the full path information was not required in the attribute even though
> there are situations (i.e. offline or non-directory location of the
> attribute) where it might be useful.
>
> jim schaad
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Sharon Boeyen
> Sent: Friday, June 02, 2000 11:42 AM
> To: '[e-mail]'
> Subject: SMIME cert dist draft and X.509
>
> I am not a regular participant on this mailing list, and therefore lack the
> history behind this draft. However, as editor of X.509, I'm wondering why
> this draft invents new data structures for requirements that, after a very
> quick review, I think that X.509 already has standardized structures to
> support. From a 509 perspective, I certainly want to understand any
> shortcomings that specification has with respect to meeting the needs of the
> applications that use public-key certificates.
>
> Regarding SMimeCapabilities themeselves; was the supportedAlgorithms
> attribute from 509 considered? If so, were there specific shortcomings that
> it had? Note that it is defined in X.509 as an attribute. Attributes can be
> stored in
> directories as part of entries (with or without being digitally signed
> and/or encrypted), they can be transferred in application protocols, they
> can be included in public-key and attribute certificates.
>
> Regarding the requirement to tie a set of supported algorithms to a specific
> certificate; the construct defined in the Internet draft is semantically an
> attribute certificate. Was an X.509 attribute certificate considered and
> rejected? If so, what were its deficiencies? Note that there are a number of
> ways to identify the holder of an X.509 attribute certificate. One of those
> is the hash of a public-key certificate. An attribute certificate that
> contained the hash of a public-key certificate and the supportedAlgorithms
> attribute seems to provide the functionality you're looking for. If you want
> a construct that includes several iterations (i.e.  the set of algorithms
> for each public-key certificate), then the X.509 construct
> attributeCertificateAttribute seems to provide this because it is a
> multivalued attribute that contains values of the attributeCertificate
> construct. Again, these can be stored in directories, stored in files,
> transferred in application protocols etc.
>
> Regarding PKI path construction; this is an area where a number of different
> groups seem to be active. I'm curious why there would be an smime specific
> mechanism for this anyway, when if there really is a problem, its probably
> not unique
> to smime. PKIX seems like a better place to solve this problem. I'm not sure
> I really understand your proposed solution. Are you focused only on
> hierarchies or also addressing networked trust models? Why store the path
> with the subject's domain when its the relying party's domain where the
> information is needed. Why associate it with a user certificate at all,
> since the same path (less the user cert) can be reused for any user certs
> signed by the same CA? X.509 has a standard attribute called pkiPath that I
> think may satisfy the requirement. This attribute contains a sequence of
> CA-certificates and its intent is that it stores paths that are frequently
> used by the relying parties within the community of a given CA. As such, it
> can be used to reduce the number of network connections and directory (or
> other protocol) requests to external domains. It is intended to be an
> optional facility that may be useful in some environments, but not necessary
> in others.
>
> With respect to all of these, my view is that, if directories are being used
> as repositories for the information, then ALL public-key certificates issued
> to a user be stored in the userCertificate attribute of their directory
> entry. This eliminates the need for specialized application-specific tools
> on the relying party side to find application specific data. If there are
> enhanced mechansims that provide potential efficiencies in an application
> specific environment these
> should be optional enhancements and not eliminate the fundamental
> interoperability requirement to store information in a common place. I hold
> the same view with respect to the pkiPath attribute. If stored in a
> directory it should not eliminate the need to store information as defined
> in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate
> attributes.
>
> I apologize in advance if, due to my lack of knowledge of the history of
> this spec, I'm asking questions that have been previously dealt with and
> closed, but felt I should at least ask, in the capacity of X.509 editor.
>
> FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or
> pdf format from the following:
>
> ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/
>
> This text has been approved by ITU and is the 2000 edition of X.509,
> although many of things I mention were in the 1997 3rd edition text as well.
>
> Sharon
>
> Sharon Boeyen
> Entrust Technologies
> [e-mail]



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA08558 for ietf-smime-bks; Fri, 7 Jul 2000 04:22:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08552 for <[e-mail]>; Fri, 7 Jul 2000 04:22:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20992; Fri, 7 Jul 2000 07:23:53 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-seclabel-01.txt
Date: Fri, 07 Jul 2000 07:23:52 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Implementing Company Classification Policy with the 
                          S/MIME Security Label
	Author(s)	: W. Nicolls
	Filename	: draft-ietf-smime-seclabel-01.txt
	Pages		: 
	Date		: 06-Jul-00
	
This document discusses how company security policy for data classification can be mapped to the S/MIME classification label.  Actual policies from 3 companies are used to provide worked examples.  
Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be included in the signed attributes of any SignedData object.  A security label attribute may be included in either the inner signature, outer signature, or both.  The syntax and processing rules for security labels are described in [ESS].
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED',  'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [MUSTSHOULD]. 
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-seclabel-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-seclabel-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-seclabel-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-seclabel-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-seclabel-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 CAA03263 for ietf-smime-bks; Fri, 7 Jul 2000 02:58:07 -0700 (PDT)
Received: from citicorp.com ([192.193.195.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03259 for <[e-mail]>; Fri, 7 Jul 2000 02:58:05 -0700 (PDT)
From: [e-mail]
Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.195.186]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA04500 for <[e-mail]>; Fri, 7 Jul 2000 05:54:47 -0400 (EDT)
Received: from x400prod2.cgin.us-md.citicorp.com ([e-mail] [163.39.249.91]) by myrtle1.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id FAA02593 for <[e-mail]>; Fri, 7 Jul 2000 05:57:05 -0400 (EDT)
Received: from mercury.lew.gb.citicorp.com (mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA26972 Fri, 7 Jul 2000 05:57:04 -0400 (EDT)
Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA02206 for [e-mail]; Fri, 7 Jul 2000 10:57:02 +0100 (BST)
X-OpenMail-Hops: 1
Date: Fri, 7 Jul 2000 10:56:57 +0100
Message-Id: <H000038a064f8dfc@MHS>
Subject: FW: Canonicalisation of embedded MIME objects
MIME-Version: 1.0
TO: [e-mail]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
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 posted this earlier but got only one response and no help.

Can anyone help or point me in the right direction where I may find 
clarification.

I am aware that the standards say "be modest in what you send and generous in 
what you accept" but It seems that a significant number of people/implementers 
are not following the standard as defined.

Bartley.

-----Original Message-----
From: O'Malley, Bartley 
Sent: Friday, June 23, 2000 1:03 PM
To: 'ietf-smime'
Subject: Canonicalisation of embedded MIME objects

I have noticed that a number of files as produced by different mail programs do 
not seem to be performing canonicalisation of inner objects correctly.

The inner objects use LF for line termination not CRLF pairs. It is my 
understanding that breaks MIME rules for canonicalising embedded objects.

To illustrate the problem I enclose a signed-then-encrypted message I have 
received:(I have removed the routing information)

The outer message appears as follows(All lines are terminated with <CRLF> 
pairs.).
-----------------------------------------------------------
Content-Type: application/pkcs7-mime; smime-type=encrypted-data;                
              name="xxx.p7m"                                                    
Content-Disposition: attachment; filename=xxx.p7m                               
Content-Transfer-Encoding: base64                                               
Message-ID: 19991015:080159:REF12345                                            
                                                                                
MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1UEBhMCVVMx        
ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW50IDICBDUa
:
:        
VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC4RdXrwyH2l        
1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WYEo+aKglqhJ        
--------------------------------------------------------------------------------
----


The embedded message looks as follows(All lines are terminated with <LF>).

----------------------------------------------------------------------------
Content-Type: application/pkcs7-mime; smime-type=signed-data;
              name="xxx.p7m"
Content-Disposition: attachment; filename=xxx.p7m
Content-Transfer-Encoding: base64
Message-ID: 19990225:131734:20499

MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKoZIhvcNAQcB
:
:
mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSlvuG6deAhgZ
XJ0KskSW4qT5
-----------------------------------------------------------------------------


The inner application file looks as follows: With Content lines terminated with 
<LF> and the data segment with no line ends.

----------------------------------------------------------------------------
Content-Type: application/EDIFACT;
              name="xxx.edi"
Content-Transfer-Encoding: binary

UNA:+.? 'UNB+UNOA:1+



-----------------------------------------------------------------------------


It is my interpretation that the use of <LF> to terminate the Content headers 
in the latter two messages above is not valid.

Can someone provide me with a definitive answer.

Thanks,
Bartley.







Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28059 for ietf-smime-bks; Thu, 6 Jul 2000 12:10:44 -0700 (PDT)
Received: from mail.treasureweb.com.hk ([152.101.116.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28053 for <[e-mail]>; Thu, 6 Jul 2000 12:10:42 -0700 (PDT)
Received: from host [38.26.242.162] by mail.treasureweb.com.hk with ESMTP (SMTPD32-5.05) id AD2765C028E; Mon, 12 Jun 2000 00:11:35 +0800
From: "Carter Mellis" <[e-mail]>
Subject: Your business depends on it #7DB7
To: cash29d
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, 11 Jun 2000 11:25:38 -0500
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <200006120011109.SM00247@host>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA28055
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>

Email marketing is starting to boom and 
you're probably wondering how you can 
capitalize on this phenomenal advertising 
method. Well..here is your chance!
 
As e-commerce grows, you need to stay 
on top of your competition and keep up with
the technology.  
 
GENIUS MARKETING STRATEGIES CAN HELP!
 
We can target a market that will advertise
your business effectively. NATIONWIDE OR 
LOCAL TARGETING IS AVAILABLE!
 
You've probably seen millions of email addresses 
on CD's for $50 or lots of companies offering
deals that seem too good to be true...
Well, they are! 
 
We are professional email marketers who 
take pride in our excellent customer service.
 
RATED #1 EMAIL MARKETERS IN
ENTREPRENEUR MAGAZINE
 
Get a head start on your competition today 
with FREE ADVERTISING CONSULTING from 
Genius Marketing Strategies.
 
Reply to mailto:[e-mail]
include your:
Name:
e-mail address:
Phone#
Web site address:
Best time to reach:
Preferred to be contacted by EMAIL or PHONE
(ALL INFORMATION MUST BE INCLUDED)
 
We except:
VISA, MASTER CARD, AND AMERICAN EXPRESS
OR CHECK BY FAX OR PHONE.


***********************************************************
Since you have received this message you have either responded
to one of our offers in the past or your address has been 
registered with us. If you wish to be removed please reply to:
mailto:[e-mail]?subject=remove
************************************************************






Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13706 for ietf-smime-bks; Wed, 5 Jul 2000 08:12:35 -0700 (PDT)
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 IAA13702 for <[e-mail]>; Wed, 5 Jul 2000 08:12:34 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA05037 for <[e-mail]>; Wed, 5 Jul 2000 08:13:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 05 Jul 2000 09:00:46 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-smime-idea-05.txt
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>

The new draft still contains the following ASN.1 for the IDEA Parameters:

      IDEA-CBCPar ::= SEQUENCE {
         IV OCTET STRING OPTIONAL -- exactly 8 octets }

First, the ASN.1 has an error because the '}' is within a comment.

Second, I see no reason for the SEQUENCE.  Has code already been written 
and deployed that uses this syntax?

Russ


At 06:44 AM 06/27/2000 -0400, [e-mail] wrote:
>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 IDEA Encryption Algorithm in CMS
>         Author(s)       : S. Teiwes, P. Hartmann, D. Kuenzi
>         Filename        : draft-ietf-smime-idea-05.txt
>         Pages           : 6
>         Date            : 26-Jun-00
>
>This memo specifies how to incorporate IDEA (International Data
>Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as
>an additional strong algorithm for symmetric encryption. For
>organizations who make use of IDEA for data security purposes
>it is of high interest that IDEA is also available in S/MIME.
>The intention of this memo is to provide the OIDs and algorithms
>required that IDEA can be included in S/MIME for symmetric content
>and key encryption.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-05.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-smime-idea-05.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-idea-05.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-idea-05.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-idea-05.txt>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA26972 for ietf-smime-bks; Tue, 4 Jul 2000 13:49:39 -0700 (PDT)
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 NAA26968 for <[e-mail]>; Tue, 4 Jul 2000 13:49:38 -0700 (PDT)
Received: from jimsch1t (ip187.du1.bel.nwlink.com [209.20.136.187]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id NAA15140 for <[e-mail]>; Tue, 4 Jul 2000 13:50:53 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: Comments on draft-ietf-smime-domsec-05.txt
Date: Tue, 4 Jul 2000 13:51:18 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
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)
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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>

1.  Should the X.400 on hetrogenous messaging be expanded to X.400/P1
similar to SMTP/MIME

2. Section 1.0 bullet 4:  Should be Heterogeneous Message Formats not
transports.  The problem is if you cannot carry the S/MIME content type not
the wrapper on the message. (Microsoft Exchange actually uses X.400 headers
with a custom content type for internal replication last time I checked and
this did not break signatures on these messages as the MIME structure was
carried intact.)

3. Section 1 last paragraph: change to more standard wording on MUST.

4. Section 2.1 formatting problem: "signature(if present)using" goes to
"signature (if present) using"

5. Section 2.2 - remove MAY from the last sentence.  This is a reason to do
the signatures, but is not part of the protocol definition. -- change MAY to
could.

6. Section 2.3 - ditto above comment for first sentence.  You can do this,
but it is not part of the protocol defintion.  change MAY to can.

7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data"

8. Section 3.0 bullet 1: This concept bothers me.  I think that there may be
some programs out there that assume atleast one signature in a signed data
object except for cases such as degenerate certs only messages.

9. Section 3.0 bullet 1: A better term for this might be a null (or empty)
signature layer.  This will difference the concept from the discussions
about signing with the NULL signature algorithm.

10. Section 3.0 bullet 2: This not clear about the presence (or absense) of
a MIME layer.  If MIME layer exists, then I fail to see the need for bullet
1 at all.

11. Section 3.0 Para 1:  Simple example of why counter-signature and
parallel signatures do or don't work for this might be called for.

12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad -
review-authority" is legal (difference between 'in' and 'as'.  Additionally
you might want to do capitalization here as utf8 strings do not do case
insensitive name compararisions (i.e. Review-Authority).  Also is cn="Jim
Schaad" cn="review-authority" legal? [By definition I think that this would
only need to be done if the review was on the innermost signature layer.  On
outer layers I don't believe the intent was that name checking of the
certificate and sender should occur otherwise signing MLAs will create lots
of havoc.]

13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be
explicity forbidden?

14. Section 3.1.1 Last Paragraphy - Please soften last sentence.  The
correct action should be to flag sender/certificate mismatch not to reject
as invalid.

15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a
description of generating and processing siganture types.  I believe that
you meant "All signatures are processed..."

16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using
the -- comment syntax of ASN.  i.e.
	id-aa-sigtype-domain-signature :: OBJECT ID {....}
		-- Domain Signature

17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about
originator signature not ecapuslating other signatures -- you are
eleminating triple wrapped signature from existance (i.e. S2(E(S1(M))) where
S1 and S2 are by the originator.

18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same
level have different content in the SigantureType attribute or not?

19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you
must remove the mlaExpansion or the first MLA outside will strip the domain
signature from the message.

20. Section 3.2 Paragarph 11 - Why is this only a MAY.  It would appear that
the correct statement is MUST as otherwise the whole process is wasted.

21. Section 3.2 Paragaph  ? - Where and how did you get the FROM address in
the message.  Unless you make a statement about including the SMTP headers
at the time of wrapping all you get is the MIME headers which do not include
this information.  (i.e. this is never going to happen unless you call for
it to happen.)

22. Section 3.2 Last Paragraph - Change to make a statement about a single
layer as well (or instead of).

23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS?

24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))).  S1 has an equivalent
label, S2 and S3 both have labels, and the labels are different.  Is the
equivalent label the same as both labels or only one?

25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST

26. Section 3.3 Paragarph Last - ditto froms ection 3.3

27. Section 3.5 - By default you can have multiple originator signatures
(potentially with different algorithms) in a message.  So the restriction in
this section makes no sense.

28. Section 4 - Where on this table would you put the case of Originator
Encrypts to Recipient Domain which encrypts to Receipient?  It would appear
to be an instance of (a), (b) and (c).

29. Section 4 Paragraphy Last-2 - How can I possibly enforce this?  For Key
Transport the sender is anonymous, for Key Agreement the senders certificate
is often not examined.  Additionally the domain component could change so
that does match -- or it might be my domain component that did the
re-enecryption and would therefore match my domain name and not the senders
domain name.

30. General - Please include ASN.1 module at the end with a list of all
defined OIDs and structures.  Get module oid from Russ.  (This request is
just pure lazyness on my part but makes some things easier.)

31. General - Do we need to specify the big brother syndrome at this time
(encrypt for end-entity and for DCA)?

jim schaad



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA20057 for ietf-smime-bks; Tue, 4 Jul 2000 07:52:51 -0700 (PDT)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20049 for <[e-mail]>; Tue, 4 Jul 2000 07:52:47 -0700 (PDT)
Received: (qmail 1894 invoked from network); 4 Jul 2000 14:53:56 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 4 Jul 2000 14:53:56 -0000
Received: (qmail 27663 invoked from network); 4 Jul 2000 14:53:55 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mailhost.eris.dera.gov.uk with SMTP; 4 Jul 2000 14:53:55 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Ietf-Smime" <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-domsec-05.txt
Date: Tue, 4 Jul 2000 15:54:22 +0100
Message-ID: <000a01bfe5c7$bd648f80$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01BFE5D0.1F28F780"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
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 multi-part message in MIME format.

------=_NextPart_000_000B_01BFE5D0.1F28F780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Jim,

Thanks for your comments.

I have responded to each of your comments below. I have also attached a
working version of the latest version of DOMSEC that reflects some of the
points you have made.

Cheers,
Bill.

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: 03 July 2000 07:40
> To: [e-mail]; [e-mail]
> Cc: Ietf-Smime
> Subject: Comments on draft-ietf-smime-domsec-05.txt
>
>
> 1.  Should the X.400 on hetrogenous messaging be expanded to X.400/P1
> similar to SMTP/MIME

Its not just P1. Have changed the text to read X.400 series. Is that better?

>
> 2. Section 1.0 bullet 4:  Should be Heterogeneous Message Formats not
> transports.  The problem is if you cannot carry the S/MIME
> content type not
> the wrapper on the message. (Microsoft Exchange actually uses
> X.400 headers
> with a custom content type for internal replication last time I
> checked and
> this did not break signatures on these messages as the MIME structure was
> carried intact.)

Done.

>
> 3. Section 1 last paragraph: change to more standard wording on MUST.

Done.

>
> 4. Section 2.1 formatting problem: "signature(if present)using" goes to
> "signature (if present) using"

Done.

>
> 5. Section 2.2 - remove MAY from the last sentence.  This is a
> reason to do
> the signatures, but is not part of the protocol definition. --
> change MAY to
> could.

Done.

>
> 6. Section 2.3 - ditto above comment for first sentence.  You can do this,
> but it is not part of the protocol defintion.  change MAY to can.

Done.

>
> 7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data"

Done.

>
> 8. Section 3.0 bullet 1: This concept bothers me.  I think that
> there may be
> some programs out there that assume atleast one signature in a signed data
> object except for cases such as degenerate certs only messages.

This may be true. However, CMS (section 5.1) states that there may be zero
signerInfos. Therefore, the problem is with those programs that expect at
least one signature.

>
> 9. Section 3.0 bullet 1: A better term for this might be a null (or empty)
> signature layer.  This will difference the concept from the discussions
> about signing with the NULL signature algorithm.

I did have concerns over this. Have changed it to empty signature layer.

>
> 10. Section 3.0 bullet 2: This not clear about the presence (or
> absense) of
> a MIME layer.  If MIME layer exists, then I fail to see the need
> for bullet
> 1 at all.


You are going to have to humour me on this point. Can you explain your
thoughts
in more detail? Points 1 and 2 are there to describe encapsulating an
unsigned and a signed message with a domain signature. Are you suggesting
that
if a MIME layer exists you don't have to specify how to apply a domain
signature
to an unsigned message?

>
> 11. Section 3.0 Para 1:  Simple example of why counter-signature and
> parallel signatures do or don't work for this might be called for.

Since we do not mention parallel signatures any more, we only support
encapsulation, I believe an example of why counter-signature and parallel
signatures do or don't work would be inappropriate and confusing.


>
> 12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad -
> review-authority" is legal (difference between 'in' and 'as'.
> Additionally
> you might want to do capitalization here as utf8 strings do not do case
> insensitive name compararisions (i.e. Review-Authority).  Also is cn="Jim
> Schaad" cn="review-authority" legal? [By definition I think that
> this would
> only need to be done if the review was on the innermost signature
> layer.  On
> outer layers I don't believe the intent was that name checking of the
> certificate and sender should occur otherwise signing MLAs will
> create lots
> of havoc.]

Good point. Changed 'in' to 'as'.

>
> 13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be
> explicity forbidden?

We do not wish to forbid this capability.

>
> 14. Section 3.1.1 Last Paragraphy - Please soften last sentence.  The
> correct action should be to flag sender/certificate mismatch not to reject
> as invalid.

Done.

>
> 15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a
> description of generating and processing siganture types.  I believe that
> you meant "All signatures are processed..."

Your right. Have changed.

>
> 16. Section 3.1.2 Paragraph ~5 - Please put text in to OID
> definition using
> the -- comment syntax of ASN.  i.e.
> 	id-aa-sigtype-domain-signature :: OBJECT ID {....}
> 		-- Domain Signature

Done.


>
> 17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about
> originator signature not ecapuslating other signatures -- you are
> eleminating triple wrapped signature from existance (i.e.
> S2(E(S1(M))) where
> S1 and S2 are by the originator.

Good point. Have changed text to allow this.


>
> 18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same
> level have different content in the SigantureType attribute or not?

No they can't have different content. Text has now been added to state this.

>
> 19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you
> must remove the mlaExpansion or the first MLA outside will strip
> the domain
> signature from the message.

Removing the mlaExpansion will not stop this in all cases. If there is an
envelopedData within the message the MLA will strip off all signatures
outside
of the envelopedData.

Any suggestions as to how to keep the domain signature?

>
> 20. Section 3.2 Paragarph 11 - Why is this only a MAY.  It would
> appear that
> the correct statement is MUST as otherwise the whole process is wasted.
>

Where are you referring to? 3.2 para 11 does not contain a MAY.


> 21. Section 3.2 Paragaph  ? - Where and how did you get the FROM
> address in
> the message.  Unless you make a statement about including the SMTP headers
> at the time of wrapping all you get is the MIME headers which do
> not include
> this information.  (i.e. this is never going to happen unless you call for
> it to happen.)

After reviewing this issue we have decided to remove this text, since even
if
this field is within the message you can not assume that it contains the
identity of the originator.

>
> 22. Section 3.2 Last Paragraph - Change to make a statement about a single
> layer as well (or instead of).

Done.

>
> 23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS?

Good catch. Done.

>
> 24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))).  S1 has an equivalent
> label, S2 and S3 both have labels, and the labels are different.  Is the
> equivalent label the same as both labels or only one?

This is outside the scope of DOMSEC. I recall this subject being discussed
before
on the list. Let a sleeping dog lie :-)

>
> 25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST

Done.

>
> 26. Section 3.3 Paragarph Last - ditto froms ection 3.3

If you are referring to the 'MAY' as in "There MAY be one or more 'domain
signature'
signatures in an S/MIME encoding" then this should be a MAY and not a MUST.

>
> 27. Section 3.5 - By default you can have multiple originator signatures
> (potentially with different algorithms) in a message.  So the
> restriction in
> this section makes no sense.

You are correct. Have removed the restriction.

>
> 28. Section 4 - Where on this table would you put the case of Originator
> Encrypts to Recipient Domain which encrypts to Receipient?  It
> would appear
> to be an instance of (a), (b) and (c).

If the originator encrypts to the recipients domain then this is case (b).
Then
when the recipients domain encrypts to the recipient this is case (c).

>
> 29. Section 4 Paragraphy Last-2 - How can I possibly enforce
> this?  For Key
> Transport the sender is anonymous, for Key Agreement the senders
> certificate
> is often not examined.  Additionally the domain component could change so
> that does match -- or it might be my domain component that did the
> re-enecryption and would therefore match my domain name and not
> the senders
> domain name.

The only extra specification to those specified in CMS is that the naming
convention and name mapping convention defined in DOMSEC is used. This is
specified to locate public keys. For example, if a domain needs to locate
the public key for the domain of the recipient [e-mail]
then the public key belonging to [e-mail].
gov.uk needs to be located, or if not present the public key of an ascendant
of the domain name needs to be located.

>
> 30. General - Please include ASN.1 module at the end with a list of all
> defined OIDs and structures.  Get module oid from Russ.  (This request is
> just pure lazyness on my part but makes some things easier.)

Done.

>
> 31. General - Do we need to specify the big brother syndrome at this time
> (encrypt for end-entity and for DCA)?

Can you foresee any problems if we do?

>
> jim schaad
>

------=_NextPart_000_000B_01BFE5D0.1F28F780
Content-Type: text/plain;
	name="draft-ietf-smime-domsec-06.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-smime-domsec-06.txt"

INTERNET-DRAFT                                                T Dean
draft-ietf-smime-domsec-06.txt                                W Ottaway
Expires ??/??/?? working version                              DERA


                    Domain Security Services using S/MIME

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

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 series and SMTP/MIME, or when a
single domain wishes to communicate securely with one of its members
residing on an untrusted domain. The scenarios covered by this document
are domain to domain, individual to domain and domain to individual
communications. 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.

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

Acknowledgements

Significant comments were made by Luis Barriga, Greg Colla, Trevor
Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.

1. Introduction

The S/MIME [1] series of standards define a data encapsulation format
for the provision of a number of security services including data
integrity, confidentiality, and authentication. S/MIME is designed for
use by messaging clients to deliver security services to distributed
messaging applications.

There are many circumstances when it is not desirable or practical to
provide end-to-end (desktop-to-desktop) security services, particularly
between different security domains. An organisation that is considering
providing end-to-end security services will typically have to deal with
some if not all of the following issues: 

1) Heterogeneous message access methods: Users are accessing mail using
   mechanisms which re-format messages, such as using Web browsers.
   Message reformatting in the Message Store makes end-to-end encryption
   and signature validation impossible.

2) Message screening and audit: Server-based mechanisms such as
   searching for prohibited words or other content, virus scanning, and
   audit, are incompatible with end-to-end encryption.

3) PKI deployment issues: There may not be any certificate paths between
   two organisations. Or an organisation may be sensitive about aspects
   of its PKI and unwilling to expose them to outside access. Also, full
   PKI deployment for all employees, may be expensive, not necessary or
   impractical for large organisations. For any of these reasons, direct
   end-to-end signature validation and encryption are impossible.

4) Heterogeneous message formats: One organisation using X.400 series
   protocols wishes to communicate with another using SMTP. Message
   reformatting at gateways makes end-to-end encryption and signature
   validation impossible.

This document describes an approach to solving these problems by
providing message security services at the level of a domain or an
organisation. This document specifies how these 'domain security
services' can be provided using the S/MIME protocol. Domain security
services may replace or complement mechanisms at the desktop. For
example, a domain may decide to provide desktop-to-desktop signatures
but domain-to-domain encryption services. Or it may allow desktop-to-
desktop services for intra-domain use, but enforce domain-based services
for communication with other domains. 

Domain services can also be used by individual members of a corporation
who are geographically remote and who wish to exchange encrypted and/or
signed messages with their base.

Whether or not a domain based service is inherently better or worse than
desktop based solutions is an open question. Some experts believe that
only end-to-end solutions can be truly made secure, while others believe
that the benefits offered by such things as content checking at domain
boundaries offers considerable increase in practical security for many
real systems. The additional service of allowing signature checking at
several points on a communications path is also an extra benefit in many
situations. This debate is outside the scope of this document. What is
offered here is a set of tools that integrators can tailor in different
ways to meet different needs in different circumstances.
 
Message transfer agents (MTAs), guards, firewalls and protocol
translation gateways all provide domain security services. As with
desktop based solutions, these components must be resilient against a
wide variety of attacks intended to subvert the security services.
Therefore, careful consideration should be given to security of these
components, to make sure that their siting and configuration minimises
the possibility of attack.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].

2. Overview of Domain Security Services

This section gives an informal overview of the security services that
are provided by S/MIME between different security domains. These
services are provided by a combination of mechanisms in the sender's and
recipient's domains.

Later sections describe definitively how these services map onto
elements of the S/MIME protocol.

The following security mechanisms are specified in this document:

1. Domain signature
2. Review signature
3. Additional attributes signature
4. Domain encryption and decryption 

The term 'security domain' as used in this document is defined as a
collection of hardware and personnel operating under a single security
authority and performing a common business function. Members of a
security domain will of necessity share a high degree of mutual trust,
due to their shared aims and objectives.

A security domain is typically protected from direct outside attack by
physical measures and from indirect (electronic) attack by a combination
of firewalls and guards at network boundaries. The interface between two
security domains is termed a 'security boundary'. One example of a
security domain is an organisational network ('Intranet').

2.1 Domain Signature 

A Domain signature is an S/MIME signature generated on behalf of a set
of users in a domain. A Domain signature can be used to authenticate
information sent between domains or between a certain domain and one of
its individuals, for example, when two 'Intranets' are connected using
the Internet, or when an Intranet is connected to a remote user over the
Internet. It can be used when two domains employ incompatible signature
schemes internally or when there are no certification links between their
PKIs. In both cases messages from the originator's domain are signed over
the original message and signature (if present) using an algorithm, key,
and certificate which can be processed by the recipient(s). A domain
signature is sometimes referred to as an "organisational signature".

2.2 Review Signature

A third party may review messages before they are forwarded to the final
recipient(s) who may be in the same or a different security domain.
Organisational policy and good security practice often require that
messages be reviewed before they are released to external recipients.
Having reviewed a message, an S/MIME signature is added to it - a review
signature. An agent could check the review signature at the domain
boundary, to ensure that only reviewed messages are released.

2.3 Additional Attributes Signature

A third party can add additional attributes to a signed message. An
S/MIME signature is used for this purpose - an additional attributes
signature. An example of an additional attribute is the 'Equivalent
Label' attribute defined in ESS [3].

2.4 Domain Encryption and Decryption

Domain encryption is S/MIME encryption performed on behalf of a
collection of users in a domain. Domain encryption can be used to
protect information between domains, for example, when two 'Intranets'
are connected using the Internet. It can also be used when end users do
not have PKI/encryption capabilities at the desktop, or when two
domains employ incompatible encryption schemes internally. In the latter
case messages from the originator's domain are (re-)encrypted using an
algorithm, key, and certificate which can be decrypted by the
recipient(s) or an entity in their domain. This scheme also applies to
protecting information between a single domain and one of its members
when both are connected using an untrusted network, e.g the Internet.

3. Mapping of the Signature Services to the S/MIME Protocol

This section describes the S/MIME protocol elements that are used to
provide the security services described above. ESS [3] introduces the
concept of triple-wrapped messages that are first signed, then
encrypted, then signed again. This document also uses this concept of
triple-wrapping. In addition, this document also uses the concept of
'signature encapsulation'. 'Signature encapsulation' denotes a signed
or unsigned message that is wrapped in a signature, this signature
covering both the content and the first (inner) signature, if present.

Signature encapsulation MAY be performed on the inner and/or the outer
signature of a triple-wrapped message. 

For example, the originator signs a message which is then encapsulated
with an 'additional attributes' signature. This is then encrypted. A
reviewer then signs this encrypted data, which is then encapsulated by
a domain signature.

A DOMSEC signature MAY encapsulate a message in one of the following
ways:  

1) An unsigned message has an empty signature layer added to it (i.e.
   the message is wrapped in a signedData that has a signerInfos which
   contains no elements). This is to enable backward compatibility with
   S/MIME software that does not have a DOMSEC capability. Since the
   signerInfos will contain no signers the eContentType, within the
   EncapsulatedContentInfo, MUST be id-data as described in CMS [5].
   However, the eContent field will contain the unsigned message instead
   of being left empty as suggested in section 5.2 in CMS [5]. This is so
   that when the DOMSEC signature is added, as defined in method 2)
   below, the signature will cover the unsigned message.

2) Signature Encapsulation is used to wrap the original signed message
   with a 'domain signature'.

3.1 Naming Conventions and Signature Types

An entity receiving an S/MIME signed message would normally expect the
signature to be that of the originator of the message. However, the
message security services defined in this document require the recipient
to be able to accept messages signed by other entities and/or the
originator. When other entities sign the message the name in the
certificate will not match the message sender's name. An S/MIME
compliant implementation would normally flag a warning if there were a
mismatch between the name in the certificate and the message sender's
name. (This check prevents a number of types of masquerade attack.)

In the case of domain security services, this warning condition SHOULD
be suppressed under certain circumstances. These circumstances are
defined by a naming convention that specifies the form that the signers
name SHOULD adhere to. Adherence to this naming convention avoids the
problems of uncontrolled naming and the possible masquerade attacks that
this would produce.

As an assistance to implementation, a signed attribute is defined to be
included in the S/MIME signature - the 'signature type' attribute. On
receiving a message containing this attribute, the naming convention
checks are invoked. 

Implementations conforming to this standard MUST support the naming
convention for signature generation and verification. Implementations
conforming to this standard MUST recognise the signature type attribute
for signature verification. Implementations conforming to this standard
MUST support the signature type attribute for signature generation.

3.1.1 Naming Conventions

The following naming conventions are specified for agents generating
signatures specified in this document:

* For a domain signature, an agent generating this signature MUST be
  named 'domain-signing-authority'

* For a review signature, an agent generating this signature MUST be
  named 'review-authority'.

* For an additional attributes signature, an agent generating this
  signature MUST be named 'attribute-authority'.

This name shall appear as the 'common name (CN)' component of the
subject field in the X.509 certificate. There MUST be only one CN 
component present. Additionally, if the certificate contains an RFC 822
address, this name shall appear in the end entity component of the
address - on the left-hand side of the '@' symbol. 

In the case of a domain signature, an additional naming rule is
defined: the 'name mapping rule'. The name mapping rule states that
for a domain signing authority, the domain component of its name MUST be
the same as, or an ascendant of, the domain name of the message
originator(s) that it is representing. The domain component is defined
as follows:

* In the case of an X.500 distinguished subject name of an X.509
  certificate, the domain component is the country, organisation,
  organisational unit, state, and locality components of the
  distinguished name. 

* If the certificate contains an RFC 822 address, the domain
  component is defined to be the RFC 822 address component on the right-
  hand side of the '@' symbol.

For example, a domain signing authority acting on behalf of John Doe of
the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,o=acme,c=us' and whose e-mail address is
[e-mail], could have a certificate containing a
distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and a
RFC 822 address of '[e-mail]'.

When the X.500 distinguished subject name has consecutive organisational
units and/or localities it is important to understand the ordering of
these values in order to determine if the domain component of the domain
signature is an ascendant. In this case, when parsing the distinguished
subject name from the root (i.e. country, locality or organisation) the
parsed organisational unit or locality is deemed to be the ascendant of
consecutive (unparsed) organisational units or localities. 

For example, a domain signing authority acting on behalf of John Doe of
the Acme corporation, whose distinguished name is 'cn=John Doe,
ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is
[e-mail], could have a certificate containing
a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme,
c=us' and a RFC 822 address of
'[e-mail]'.

Any message received where the domain component of the domain signing
agents name does not match, or is not an ascendant of, the originator's
domain name MUST be rejected. 

This naming rule prevents agents from one organisation masquerading as
domain signing authorities on behalf of another. For the other types of
signature defined in this document, no such named mapping rule is
defined.

Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations MAY choose to
supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains prior
to secure exchange of messages.

On verifying the signature, a receiving agent MUST ensure that the
naming convention has been adhered to. Any message that violates the
convention should be flagged.

3.1.2 Signature Type Attribute

An S/MIME signed attribute is used to indicate the type of signature.
This should be used in conjunction with the naming conventions specified
in the previous section. When an S/MIME signed message containing the
signature type attribute is received it triggers the software to verify
that the correct naming convention has been used.

The ASN.1 [4] notation of this attribute is: -

   SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

   id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
       us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28}

If present, the SignatureType attribute MUST be a signed attribute, as
defined in [5]. If the SignatureType attribute is absent the recipient
SHOULD assume that the signature is that of the message originator.

All of the signatures defined here are generated and processed as
described in [5]. They are distinguished by the presence of the
following values in the SignatureType signed attribute:

id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 }
-- domain signature.

id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
 3} -- additional attributes signature.

id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} --
review signature.

For completeness, an attribute type is also specified for an originator
signature. However, this signature type is optional. It is defined as
follows: 

id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1}
-- originator's signature.

All signature types, except the originator type, MUST encapsulate other
signature types specified in this document MUST encapsulate other
signatures. Note the domain signature could be encapsulating an empty
signature as defined in section 3.

A SignerInfo MUST NOT include multiple instances of SignatureType. A
signed attribute representing a SignatureType MAY include multiple
instances of different SignatureType values as an AttributeValue of
attrValues [5], as long as the SignatureType 'additional attributes' is
not present.

If there is more than one SignerInfo in a signerInfos (i.e. when
different algorithms are used) then the SignatureType attribute in all
the SignerInfos MUST contain the same content. 

The following sections describe the conditions under which each of these
types of signature may be generated, and how they are processed.

3.2 Domain Signature Generation and Verification

A 'domain signature' is a proxy signature generated on a user's behalf
in the user's domain. The signature MUST adhere to the naming
conventions in 3.1.1, including the name mapping convention. A 'domain
signature' on a message authenticates the fact that the message has
originated in that domain. Before signing, a process generating a
'domain signature' MUST first satisfy itself of the authenticity of the
message originator. This is achieved by one of two methods. Either the
'originator's signature' is checked, if S/MIME signatures are used
inside a domain. Or if not, some mechanism external to S/MIME is used,
such as the physical address of the originating client or an
authenticated IP link.

If the originator's authenticity is successfully verified by one of the
above methods and all other signatures present are valid, a 'domain
signature' MAY be added to a message.

An entity generating a domain signature MUST do so using a certificate
containing a subject name that follows the naming convention specified
in 3.1.1.

When a 'domain signature' is applied the mlExpansionHistory and
eSSSecurityLabel attributes MUST be copied from other signerInfos as
stated in [3].

If the originator's authenticity is not successfully verified or all
the signatures present are not valid, a 'domain signature' MUST NOT be
generated.

On reception, the 'domain signature' SHOULD be used to verify the
authenticity of a message. A check MUST be made to ensure that both the
naming convention and the name mapping convention have been used as
specified in this standard.

A recipient can assume that successful verification of the domain
signature also authenticates the message originator.

If there is an originator signature present, the name in that
certificate SHOULD be used to identify the originator. This information
can then be displayed to the recipient.

If there is no originator signature present, the only assumption that can
be made is the domain the message originated from.

A domain signer can be assumed to have verified any signatures that it
encapsulates. Therefore, it is not necessary to verify these signatures
before treating the message as authentic. However, this standard does
not preclude a recipient from attempting to verify any other signatures
that are present.

The 'domain signature' is indicated by the presence of the value
id-aa-sigtype-domain-sig in a 'signature type' signed attribute.

There MAY be one or more 'domain signature' signatures in an S/MIME
encoding.

3.3 Additional Attributes Signature Generation and Verification

The 'additional attributes' signature type indicates that the
SignerInfo contains additional attributes that are associated with the
message.

All attributes in the applicable SignerInfo MUST be treated as
additional attributes. Successful verification of an 'additional
attributes' signature means only that the attributes are authentically
bound to the message. A recipient MUST NOT assume that its successful
verification also authenticates the message originator. 

An entity generating an 'additional attributes' signature MUST do so
using a certificate containing a subject name that follows the naming
convention specified in 3.1.1. On reception, a check MUST be made to
ensure that the naming convention has been used.

A signer MAY include any of the attributes listed in [3] or in this
document when generating an 'additional attributes' signature. The
following attributes have a special meaning, when present in an
'additional attributes' signature:

1) Equivalent Label: label values in this attribute are to be treated as
   equivalent to the security label contained in an encapsulated
   SignerInfo, if present.

2) Security Label: the label value indicates the aggregate sensitivity
   of the inner message content plus any encapsulated signedData and
   envelopedData containers. The label on the original data is indicated
   by the value in the originator's signature, if present.

An 'additional attributes' signature is indicated by the presence of the
value id-aa-sigtype-add-attrib-sig in a 'signature type' signed
attribute. Other Object Identifiers MUST NOT be included in the sequence
of OIDs if this value is present. 

There MAY be multiple 'additional attributes' signatures in an S/MIME
encoding.

3.4 Review Signature Generation and Verification

The review signature indicates that the signer has reviewed the message.
Successful verification of a review signature means only that the signer
has approved the message for onward transmission to the recipient(s).
When the recipient is in another domain, a device on a domain boundary
such as a Mail Guard or firewall may be configured to check review
signatures. A recipient MUST NOT assume that its successful verification
also authenticates the message originator.

An entity generating a signed review signature MUST do so using a
certificate containing a subject name that follows the naming convention
specified in 3.1.1. On reception, a check MUST be made to ensure that
the naming convention has been used.

A review signature is indicated by the presence of the value
id-aa-sigtype-review-sig in a 'signature type' signed attribute.

There MAY be multiple review signatures in an S/MIME encoding.

3.5 Originator Signature

The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. It is included in this
document for completeness only. An originator signature is indicated
either by the absence of the signature type attribute, or by the
presence of the value id-aa-sigtype-originator-sig in a 'signature type'
signed attribute.

4. Encryption and Decryption

Message encryption may be performed by a third party on behalf of a set
of originators in a domain. This is referred to as domain encryption.
Message decryption may be performed by a third party on behalf of a set
of recipients in a domain.  This is referred to as domain decryption.
The third party that performs these processes is referred to in this
section as a "Domain Confidentiality Authority" (DCA). Both of these
processes are described in this section.

Messages may be encrypted for decryption by the final recipient and/or
by a DCA in the recipient's domain. The message may also be encrypted
for decryption by a DCA in the originator's domain (e.g. for content
analysis, audit, key word scanning, etc.). The choice of which of these
is actually performed is a system specific issue that depends on system
security policy. It is therefore outside the scope of this document.
These processes of encryption and decryption processes are shown in the
following table.

  --------------------------------------------------------------------
 |                        | Recipient Decryption |  Domain Decryption |
 |------------------------|----------------------|--------------------|
 | Originator Encryption  |       Case(a)        |       Case(b)      |
 | Domain Encryption      |       Case(c)        |       Case(d)      |
  --------------------------------------------------------------------

Case (a), encryption of messages by the originator for decryption by the
final recipient(s), is described in CMS [5]. In cases (c) and (d),
encryption is performed not by the originator but by the DCA in the
originator's domain. In Cases (b) and (d), decryption is performed not
by the recipient(s) but by the DCA in the recipient's domain.  

A client implementation that conforms to this standard MUST support
case (b) for transmission, case (c) for reception and case (a) for
transmission and reception. 

A DCA implementation that conforms to this standard MUST support cases
(c) and (d), for transmission, and cases (b) and (d) for reception.

The process of encryption and decryption is documented in CMS [5]. The
only additional requirement introduced by domain encryption and
decryption is for greater flexibility in the management of keys, as
described in the following subsections. As with signatures, a naming
convention and name mapping convention are used to locate the correct
public key.

The mechanisms described below are applicable both to key agreement and
key transport systems, as documented in CMS [5]. The phrase 'encryption
key' is used as a collective term to cover the key management keys used
by both techniques.

The mechanisms below are also applicable to individual roving users who
wish to encrypt messages that are sent back to base.

4.1 Domain Confidentiality Naming Conventions 

A DCA MUST be named 'domain-confidentiality-authority'. This name MUST
appear in the 'common name(CN)' component of the subject field in the
X.509 certificate. Additionally, if the certificate contains an RFC 822
address, this name MUST appear in the end entity component of the
address - on the left-hand side of the '@' symbol. 

Along with this naming convention, an additional naming rule is defined:
the 'name mapping rule'. The name mapping rule states that for a DCA,
the domain component of its name MUST be the same as, or an ascendant
of, the domain name of the set of entities that it represents. The
domain component is defined as follows:

* In the case of an X.500 distinguished name of an X.509 certificate,
  the domain component is the country, organisation, organisational
  unit, state, and locality components of the distinguished name. 

* If the certificate contains an RFC 822 address, the domain component
  is defined to be the RFC 822 address component on the right-hand side
  of the '@' symbol.

For example, a DCA acting on behalf of John Doe of the Acme
corporation, whose distinguished name is 'cn=John Doe, ou=marketing,
o=acme,c=us' and whose e-mail address is [e-mail],
could have a certificate containing a distinguished name of 
'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail
address of '[e-mail]'. The key
associated with this certificate would be used for encrypting messages
for John Doe.

Any message received where the domain component of the domain encrypting
agents name does not match, or is not an ascendant of, the domain name
of the entities it represents MUST be rejected. 

This naming rule prevents messages being encrypted for the wrong domain
decryption agent.

Implementations conforming to this standard MUST support this name
mapping convention as a minimum. Implementations may choose to
supplement this convention with other locally defined conventions.
However, these MUST be agreed between sender and recipient domains
prior to sending any messages.

4.2 Key Management for DCA Encryption

At the sender's domain, DCA encryption is achieved using the recipient
DCA's certificate or the end recipient's certificate. For this, the
encrypting process must be able to correctly locate the certificate to
the corresponding DCA in the recipient's domain or the one corresponding
to the end recipient. Having located the correct certificate, the
encryption process is then performed and additional information required
for decryption is conveyed to the recipient in the recipientInfo field
as specified in CMS [5]. A DCA encryption agent MUST be named according
to the naming convention specified in section 4.1. This is so that the
corresponding certificate can be used on eventual reply to a DCA
encrypted message.

DCA encryption may be performed for decryption by the end recipient
and/or by a DCA. End recipient decryption is described in CMS [5]. DCA
decryption is described in section 4.3.

4.3 Key Management for DCA Decryption 

DCA decryption uses a private-key from the recipient's domain and the
necessary information conveyed in the recipientInfo field. The
private-key is owned by the DCA for the recipient domain. This is
achieved using the naming conventions specified in 4.1. It is vital that
these conventions are adhered to, in order to maintain confidentiality.

It should be noted that domain decryption can be performed on messages
encrypted by the originator and/or by a DCA in the originator's domain.
In the first case, the encryption process is described in CMS [5]; in
the second case, the encryption process is described in 4.2.

No specific method for locating this certificate is mandated in this
document. An implementation may choose to access a local certificate
store to locate the correct certificate. Alternatively, a directory may
be used in one of the following ways: 

1. The directory may store the DCA certificate in the recipient's
   directory entry. When the user certificate attribute is requested,
   this certificate is returned. 

2. The encrypting agent maps the recipient`s name to the DCA name in the
   manner specified in 4.1. The user certificate attribute associated
   with this directory entry is then obtained. 

This document does not mandate either of these processes. Whichever one
is used, the name mapping conventions must be adhered to, in order to
maintain confidentiality. 

Having located the correct certificate, the encryption process is then
performed. A recipientInfo for the DCA is then generated, as described
in CMS [5].

5. Security Considerations

Implementations MUST protect all private keys. Compromise of the
signer's private key permits masquerade.  

Similarly, compromise of the content-encryption key may result in
disclosure of the encrypted content.

Compromise of key material is regarded as an even more serious issue for
domain security services than for an S/MIME client. This is because
compromise of the private key may in turn compromise the security of a
whole domain. Therefore, great care should be used when considering its
protection.

Domain encryption alone is not secure and should be used in conjuction
with a domain signature to avoid a masquerade attack, where an attacker
that has obtain a DCA cert can fake a message to that domain pretending
to be another domain. 

6. DOMSEC ASN.1 Module

DOMSECSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) <TBD> }

    DEFINITIONS IMPLICIT TAGS ::=
    BEGIN

    -- EXPORTS All
    -- The types and values defined in this module are exported for
    -- use in the other ASN.1 modules.  Other applications may use
    -- them for their own purposes.

    SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

    id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
       us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28}

    id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType
    2 } -- domain signature.

    id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= {
    id-aa-signatureType 3} -- additional attributes signature.

    id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4}
    -- review signature.

    id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= {
    id-aa-signatureType 1} -- originator's signature.

    END -- of DOMSECSyntax

7. References

[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633,
    June 1999.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
    Levels", BCP 14, RFC 2119, March 1997.

[3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
    June 1999.

[4] International Telecommunications Union, Recommendation X.208, "Open
    systems interconnection: specification of Abstract Syntax Notation
    (ASN.1)", CCITT Blue Book, 1989.

[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

8. Authors' Addresses

Tim Dean
DERA Malvern
St. Andrews Road
Malvern
Worcs
WR14 3PS

Phone: [phone]
Fax:   [phone]
Email: [e-mail]

William Ottaway
DERA Malvern
St. Andrews Road
Malvern
Worcs
WR14 3PS

Phone: [phone]
Fax:   [phone]
Email: [e-mail]

8. Full Copyright Statement

"Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the  purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."

This draft expires ??/??/?? working version

------=_NextPart_000_000B_01BFE5D0.1F28F780--



Received: by ns.secondary.com (8.9.3/8.9.3) id TAA05578 for ietf-smime-bks; Mon, 3 Jul 2000 19:07:31 -0700 (PDT)
Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA05573 for <[e-mail]>; Mon, 3 Jul 2000 19:07:30 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p04320410b586f77bf008@[165.227.249.13]>
Date: Mon, 3 Jul 2000 19:08:34 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: Document Action: Use of the IDEA Encryption Algorithm in CMS to Informational
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>

Greetings. Due to a mailing list admin blip (discovered by Jim 
Schaad), this didn't make it to the list.

>To: IETF-Announce: ;
>Cc: RFC Editor <[e-mail]>
>Cc: Internet Architecture Board <[e-mail]>
>Cc: [e-mail]
>From: The IESG <[e-mail]>
>Subject: Document Action: Use of the IDEA Encryption Algorithm in CMS
>	to Informational
>Date: Fri, 30 Jun 2000 06:42:46 -0400
>Sender: [e-mail]
>
>
>
>The IESG has approved the Internet-Draft 'Use of the IDEA Encryption
>Algorithm in CMS' <draft-ietf-smime-idea-05.txt> as a Informational
>RFC.  This document is the product of the S/MIME Mail Security Working
>Group.  The IESG contact persons are Jeffrey Schiller and Marcus
>Leech.
>
>
>Note to RFC Editor:
>
>Please be sure to insert the IPR text from RFC2026 prior to publication.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA06538 for ietf-smime-bks; Sun, 2 Jul 2000 23:38:07 -0700 (PDT)
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 XAA06533 for <[e-mail]>; Sun, 2 Jul 2000 23:38:06 -0700 (PDT)
Received: from jimsch1t (ip179.du1.bel.nwlink.com [209.20.136.179]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id XAA25631; Sun, 2 Jul 2000 23:39:07 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Ietf-Smime" <[e-mail]>
Subject: Comments on draft-ietf-smime-domsec-05.txt
Date: Sun, 2 Jul 2000 23:39:33 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
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
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>

1.  Should the X.400 on hetrogenous messaging be expanded to X.400/P1
similar to SMTP/MIME

2. Section 1.0 bullet 4:  Should be Heterogeneous Message Formats not
transports.  The problem is if you cannot carry the S/MIME content type not
the wrapper on the message. (Microsoft Exchange actually uses X.400 headers
with a custom content type for internal replication last time I checked and
this did not break signatures on these messages as the MIME structure was
carried intact.)

3. Section 1 last paragraph: change to more standard wording on MUST.

4. Section 2.1 formatting problem: "signature(if present)using" goes to
"signature (if present) using"

5. Section 2.2 - remove MAY from the last sentence.  This is a reason to do
the signatures, but is not part of the protocol definition. -- change MAY to
could.

6. Section 2.3 - ditto above comment for first sentence.  You can do this,
but it is not part of the protocol defintion.  change MAY to can.

7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data"

8. Section 3.0 bullet 1: This concept bothers me.  I think that there may be
some programs out there that assume atleast one signature in a signed data
object except for cases such as degenerate certs only messages.

9. Section 3.0 bullet 1: A better term for this might be a null (or empty)
signature layer.  This will difference the concept from the discussions
about signing with the NULL signature algorithm.

10. Section 3.0 bullet 2: This not clear about the presence (or absense) of
a MIME layer.  If MIME layer exists, then I fail to see the need for bullet
1 at all.

11. Section 3.0 Para 1:  Simple example of why counter-signature and
parallel signatures do or don't work for this might be called for.

12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad -
review-authority" is legal (difference between 'in' and 'as'.  Additionally
you might want to do capitalization here as utf8 strings do not do case
insensitive name compararisions (i.e. Review-Authority).  Also is cn="Jim
Schaad" cn="review-authority" legal? [By definition I think that this would
only need to be done if the review was on the innermost signature layer.  On
outer layers I don't believe the intent was that name checking of the
certificate and sender should occur otherwise signing MLAs will create lots
of havoc.]

13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be
explicity forbidden?

14. Section 3.1.1 Last Paragraphy - Please soften last sentence.  The
correct action should be to flag sender/certificate mismatch not to reject
as invalid.

15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a
description of generating and processing siganture types.  I believe that
you meant "All signatures are processed..."

16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using
the -- comment syntax of ASN.  i.e.
	id-aa-sigtype-domain-signature :: OBJECT ID {....}
		-- Domain Signature

17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about
originator signature not ecapuslating other signatures -- you are
eleminating triple wrapped signature from existance (i.e. S2(E(S1(M))) where
S1 and S2 are by the originator.

18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same
level have different content in the SigantureType attribute or not?

19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you
must remove the mlaExpansion or the first MLA outside will strip the domain
signature from the message.

20. Section 3.2 Paragarph 11 - Why is this only a MAY.  It would appear that
the correct statement is MUST as otherwise the whole process is wasted.

21. Section 3.2 Paragaph  ? - Where and how did you get the FROM address in
the message.  Unless you make a statement about including the SMTP headers
at the time of wrapping all you get is the MIME headers which do not include
this information.  (i.e. this is never going to happen unless you call for
it to happen.)

22. Section 3.2 Last Paragraph - Change to make a statement about a single
layer as well (or instead of).

23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS?

24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))).  S1 has an equivalent
label, S2 and S3 both have labels, and the labels are different.  Is the
equivalent label the same as both labels or only one?

25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST

26. Section 3.3 Paragarph Last - ditto froms ection 3.3

27. Section 3.5 - By default you can have multiple originator signatures
(potentially with different algorithms) in a message.  So the restriction in
this section makes no sense.

28. Section 4 - Where on this table would you put the case of Originator
Encrypts to Recipient Domain which encrypts to Receipient?  It would appear
to be an instance of (a), (b) and (c).

29. Section 4 Paragraphy Last-2 - How can I possibly enforce this?  For Key
Transport the sender is anonymous, for Key Agreement the senders certificate
is often not examined.  Additionally the domain component could change so
that does match -- or it might be my domain component that did the
re-enecryption and would therefore match my domain name and not the senders
domain name.

30. General - Please include ASN.1 module at the end with a list of all
defined OIDs and structures.  Get module oid from Russ.  (This request is
just pure lazyness on my part but makes some things easier.)

31. General - Do we need to specify the big brother syndrome at this time
(encrypt for end-entity and for DCA)?

jim schaad



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08429 for ietf-smime-bks; Sat, 1 Jul 2000 13:26:24 -0700 (PDT)
Received: from ns01.planet.net.tr (ns01.planet.net.tr [212.174.4.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08422 for <[e-mail]>; Sat, 1 Jul 2000 13:25:50 -0700 (PDT)
Received: from host (ip233.providence11.ri.pub-ip.psi.net [38.26.242.233]) by ns01.planet.net.tr (8.9.3/8.8.7) with ESMTP id WAA07224; Sat, 1 Jul 2000 22:33:08 +0300
Message-Id: <[e-mail]>
From: "Darren Fern" <[e-mail]>
Subject: Your Chance #220F
To: [e-mail]
X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999)
Mime-Version: 1.0
Date: Sat, 01 Jul 2000 07:42:32 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
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>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

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

***** This is an HTML Message ! *****


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

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    <meta http-equiv=3D"Content-Type"
 content=3D"text/html; charset=3Diso-8859-1">
    <meta name=3D"GENERATOR" content=3D"Mozilla/4=2E51
 [en] (Win95; I) [Netscape]">
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#FFFF99"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Dear
 Candidate,</font></font>
 <p><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">You were recently
 selected by The Office of the
 Managing</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Director for
 a free listing on The International
 Executive</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Who's
 Who=2E</font></font>
 <p><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Our Researchers
 gather information from many
 recognized</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">sources, including
 professional associations and
 societies,</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">trade organizations,
 newspaper and magazine articles,</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">professional
 reference publications, web presence,
 and</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">referrals
 from existing members=2E</font></font>
 <p><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">As a highly
 respected professional in your field
 of</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">expertise,
 we believe your contributions merit
 very</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">serious consideration
 for inclusion on The International</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Executive
 Who's Who=2E&nbsp; To maintain the
 highest</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">level of accuracy,
 we ask you fill out the brief bit
 of</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">information
 below required for inclusion=2E</font></font>
 <p><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">There is no
 cost or obligation to be listed on
 The</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">International
 Executive  Who's Who=2E</font></font>
 <br>&nbsp;
 <p><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">My Sincere
 Thanks,</font></font>
 <p><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Lorraine A=2E
 Michaels</font></font>
 <br><font face=3D"Times New Roman,Times"><font
 color=3D"#000000">Office Of
 Managing Director</font></font>
 <p>
 <hr WIDTH=3D"100%">
 <br><font color=3D"#000000"><font size=3D-1>The
 International Executive Who's Who
 is not affiliated or associated with Marquis
 Who's Who=2E</font></font>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }
 
 // -->
 
 </script>
 
 
 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->
 
 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:kb92t@webmail=2Ebellsouth=2Enet?SUBJECT=3DInternet Lead=
"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>
 
 <tr>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive
 Who's Who</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive  Who's Who=2E For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive
 Who's Who=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>
 
 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 
 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax
 
 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of www=2E&nbsp; Confirmation of its delivery=

 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><font color=3D"#000000"><font size=3D-1>The International Executive
 is not affiliated or associated with Marquis Who's Who=2E</font></font>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font color=3D"#000000"><font size=3D+1>List
 Removal</font></font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:b92mv@netscape=2Enet?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--