es as low as 2.9%.
Don't believe me? Fill out our small online form and we'll show you how.
Get the house and/or car you always wanted, it only takes 2 minutes of your time:
http://xdtyiuiipthub.giwurks.info
No thanks
From owner-ietf-smime@mail.imc.org Tue Mar 16 16:31:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26531
for ; Tue, 16 Mar 2004 16:31:36 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL0X3H062305;
Tue, 16 Mar 2004 13:00:33 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2GL0XOK062304;
Tue, 16 Mar 2004 13:00:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL0WjZ062297
for ; Tue, 16 Mar 2004 13:00:33 -0800 (PST)
(envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24382;
Tue, 16 Mar 2004 16:00:34 -0500 (EST)
Message-Id: <200403162100.QAA24382@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
Date: Tue, 16 Mar 2004 16:00:34 -0500
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-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 : Cryptographic Message Syntax (CMS)
Author(s) : R. Housley
Filename : draft-ietf-smime-rfc3369bis-00.txt
Pages : 53
Date : 2004-3-16
This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-smime-rfc3369bis-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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-smime-rfc3369bis-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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-3-16162515.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc3369bis-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smime-rfc3369bis-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-3-16162515.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ietf-smime@mail.imc.org Tue Mar 16 17:24:11 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00023
for ; Tue, 16 Mar 2004 17:24:11 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLx4Zw065298;
Tue, 16 Mar 2004 13:59:04 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2GLx49J065297;
Tue, 16 Mar 2004 13:59:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2GLx4s7065290
for ; Tue, 16 Mar 2004 13:59:04 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 26172 invoked by uid 0); 16 Mar 2004 21:52:02 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.156)
by woodstock.binhost.com with SMTP; 16 Mar 2004 21:52:02 -0000
Message-Id: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 16 Mar 2004 16:58:49 -0500
To: ietf-smime@imc.org
From: Russ Housley
Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
In-Reply-To: <200403162100.QAA24382@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Dear S/MIME WG:
Yes, we are making another round of updates to CMS. I expect them to be
very minor. The changes are described in Section 1.2, which says:
This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC
3369 introduced an extension mechanism to support new key management
schemes without further changes to the CMS. This document introduces
a similar extension mechanism to support additional certificate
formats for the verification of digital signatures without further
changes to the CMS. Backward compatibility with both RFC 2630 and
RFC 3369 is preserved.
I expect to fold in all of the changes needed to correct the errata posted
on the RFC Editor's web site in the next version. Also, Peter Gutmann has
asked for some clarification of countersignature. Finally, Jim Schaad has
suggested that support for "other format" revocation status information is
appropriate since "other format" certificates are being supported.
I do not expect these changes to take long. I will post -01 before the end
of the week.
Russ
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the
>IETF.
>
> Title : Cryptographic Message Syntax (CMS)
> Author(s) : R. Housley
> Filename : draft-ietf-smime-rfc3369bis-00.txt
> Pages : 53
> Date : 2004-3-16
>
>This document describes the Cryptographic Message Syntax (CMS). This
> syntax is used to digitally sign, digest, authenticate, or encrypt
> arbitrary message content.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-00.txt
From owner-ietf-smime@mail.imc.org Tue Mar 16 20:24:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10332
for ; Tue, 16 Mar 2004 20:24:43 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H0x7HQ075451;
Tue, 16 Mar 2004 16:59:07 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2H0x7aC075450;
Tue, 16 Mar 2004 16:59:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from [63.202.92.152] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65])
(authenticated bits=0)
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H0x5fV075439;
Tue, 16 Mar 2004 16:59:06 -0800 (PST)
(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id:
In-Reply-To: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com>
References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com>
Date: Tue, 16 Mar 2004 16:59:09 -0800
To: Russ Housley , ietf-smime@imc.org
From: Paul Hoffman / IMC
Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
At 4:58 PM -0500 3/16/04, Russ Housley wrote:
>Dear S/MIME WG:
>
>Yes, we are making another round of updates to CMS. I expect them
>to be very minor. The changes are described in Section 1.2, which
>says:
>
> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC
> 3369 introduced an extension mechanism to support new key management
> schemes without further changes to the CMS. This document introduces
> a similar extension mechanism to support additional certificate
> formats for the verification of digital signatures without further
> changes to the CMS. Backward compatibility with both RFC 2630 and
> RFC 3369 is preserved.
Maybe I'm being blind, but *where* is that extension mechanism
introduced in the new document? Listing it explicitly in this
introductory material would help the reader (or at least me...).
--Paul Hoffman, Director
--Internet Mail Consortium
From owner-ietf-smime@mail.imc.org Tue Mar 16 20:35:55 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11429
for ; Tue, 16 Mar 2004 20:35:55 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1J5Ks076412;
Tue, 16 Mar 2004 17:19:05 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2H1J5ZL076411;
Tue, 16 Mar 2004 17:19:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1J3Jj076402;
Tue, 16 Mar 2004 17:19:04 -0800 (PST)
(envelope-from shenson@drh-consultancy.demon.co.uk)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10])
by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1)
id 1B3Pi7-0007oS-0V; Wed, 17 Mar 2004 01:19:07 +0000
Message-ID: <4057A78D.9030204@drh-consultancy.demon.co.uk>
Date: Wed, 17 Mar 2004 01:19:09 +0000
From: Dr Stephen Henson
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / IMC
CC: ietf-smime@imc.org
Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com>
In-Reply-To:
X-Enigmail-Version: 0.83.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Paul Hoffman / IMC wrote:
>
> At 4:58 PM -0500 3/16/04, Russ Housley wrote:
>
>> Dear S/MIME WG:
>>
>> Yes, we are making another round of updates to CMS. I expect them to
>> be very minor. The changes are described in Section 1.2, which says:
>>
>> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC
>> 3369 introduced an extension mechanism to support new key management
>> schemes without further changes to the CMS. This document introduces
>> a similar extension mechanism to support additional certificate
>> formats for the verification of digital signatures without further
>> changes to the CMS. Backward compatibility with both RFC 2630 and
>> RFC 3369 is preserved.
>
>
> Maybe I'm being blind, but *where* is that extension mechanism
> introduced in the new document? Listing it explicitly in this
> introductory material would help the reader (or at least me...).
>
Presumably the CertificateChoices type mentioned in 10.2.2 and its use
in CertificateSet.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
From owner-ietf-smime@mail.imc.org Tue Mar 16 21:07:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12990
for ; Tue, 16 Mar 2004 21:07:51 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1nwA2078047;
Tue, 16 Mar 2004 17:49:58 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2H1nwZr078046;
Tue, 16 Mar 2004 17:49:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1nv9Y078038;
Tue, 16 Mar 2004 17:49:57 -0800 (PST)
(envelope-from jimsch@nwlink.com)
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237])
by smtp2.pacifier.net (Postfix) with ESMTP
id 8BC7E6ABA3; Tue, 16 Mar 2004 17:50:02 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To: "'Dr Stephen Henson'" ,
"'Paul Hoffman / IMC'"
Cc:
Subject: RE: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
Date: Tue, 16 Mar 2004 17:54:40 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <4057A78D.9030204@drh-consultancy.demon.co.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQLwLmtnAH/WQtDRLmZ44pQHVnX2wAAfelg
Message-Id: <20040317015002.8BC7E6ABA3@smtp2.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Steve is correct. The change was made by adding the OtherCertFormat data
type to section 10.2.2.
However I think that it is easier for people to find if the section number
is included in the changes section.
jim
-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org]
On Behalf Of Dr Stephen Henson
Sent: Tuesday, March 16, 2004 5:19 PM
To: Paul Hoffman / IMC
Cc: ietf-smime@imc.org
Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
Paul Hoffman / IMC wrote:
>
> At 4:58 PM -0500 3/16/04, Russ Housley wrote:
>
>> Dear S/MIME WG:
>>
>> Yes, we are making another round of updates to CMS. I expect them to
>> be very minor. The changes are described in Section 1.2, which says:
>>
>> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC
>> 3369 introduced an extension mechanism to support new key management
>> schemes without further changes to the CMS. This document introduces
>> a similar extension mechanism to support additional certificate
>> formats for the verification of digital signatures without further
>> changes to the CMS. Backward compatibility with both RFC 2630 and
>> RFC 3369 is preserved.
>
>
> Maybe I'm being blind, but *where* is that extension mechanism
> introduced in the new document? Listing it explicitly in this
> introductory material would help the reader (or at least me...).
>
Presumably the CertificateChoices type mentioned in 10.2.2 and its use in
CertificateSet.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
From owner-ietf-smime@mail.imc.org Wed Mar 17 11:24:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16942
for ; Wed, 17 Mar 2004 11:24:45 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HG2K1a013948;
Wed, 17 Mar 2004 08:02:20 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2HG2Kuv013947;
Wed, 17 Mar 2004 08:02:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2HG2J0M013924
for ; Wed, 17 Mar 2004 08:02:19 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 26849 invoked by uid 0); 17 Mar 2004 15:55:05 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.132.209)
by woodstock.binhost.com with SMTP; 17 Mar 2004 15:55:05 -0000
Message-Id: <5.2.0.9.2.20040317105944.01f7d848@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 17 Mar 2004 11:01:36 -0500
To: Paul Hoffman / IMC , ietf-smime@imc.org
From: Russ Housley
Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt
In-Reply-To:
References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com>
<5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Paul:
Se section 10.2.2.
Russ
At 04:59 PM 3/16/2004 -0800, Paul Hoffman / IMC wrote:
>At 4:58 PM -0500 3/16/04, Russ Housley wrote:
>>Dear S/MIME WG:
>>
>>Yes, we are making another round of updates to CMS. I expect them to be
>>very minor. The changes are described in Section 1.2, which says:
>>
>> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC
>> 3369 introduced an extension mechanism to support new key management
>> schemes without further changes to the CMS. This document introduces
>> a similar extension mechanism to support additional certificate
>> formats for the verification of digital signatures without further
>> changes to the CMS. Backward compatibility with both RFC 2630 and
>> RFC 3369 is preserved.
>
>Maybe I'm being blind, but *where* is that extension mechanism introduced
>in the new document? Listing it explicitly in this introductory material
>would help the reader (or at least me...).
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
From skdiocesz@crosslink.net Thu Mar 18 04:22:19 2004
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28956
for ; Thu, 18 Mar 2004 04:22:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1B3tjH-0004eF-00
for smime-archive@ietf.org; Thu, 18 Mar 2004 04:22:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B3tiS-0004WD-00
for smime-archive@ietf.org; Thu, 18 Mar 2004 04:21:29 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
by ietf-mx with esmtp (Exim 4.12)
id 1B3thh-0004Ng-00
for smime-archive@ietf.org; Thu, 18 Mar 2004 04:20:41 -0500
Received: from [211.236.186.177] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1B3thi-0005dD-4Z
for smime-archive@ietf.org; Thu, 18 Mar 2004 04:20:42 -0500
Received: from 207.20.120.7 by 211.236.186.177; Thu, 18 Mar 2004 14:17:10 +0500
Message-ID:
From: "Teddy Madrid"
Reply-To: "Teddy Madrid"
To: smime-archive@ietf.org
Subject: Free Prescriptions
Date: Thu, 18 Mar 2004 04:17:10 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--8395449138024609103"
X-IP: 218.8.108.141
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: Yes, hits=9.9 required=5.0 tests=BIZ_TLD,CLICK_BELOW,
FORGED_RCVD_NET_HELO,HTML_30_40,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,
HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,
ONLINE_PHARMACY,RCVD_NUMERIC_HELO,SUB_FREE_OFFER autolearn=no
version=2.60
X-Spam-Report:
* 0.5 SUB_FREE_OFFER Subject starts with "Free"
* 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO
* 2.4 ONLINE_PHARMACY BODY: Online Pharmacy
* 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.1 HTML_FONT_BIG BODY: HTML has a big font
* 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette
* 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset
* 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain
* 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network
* 0.0 CLICK_BELOW Asks you to click below
* 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts
----8395449138024609103
Content-Type: text/html;
Content-Transfer-Encoding: 7Bit
SuperMeds
Online Pharmacy
Prescriptions You
Need At Prices You Deserve! |
View our expanded
product line and new
low prices today!
Click Here To Start Saving
|
Sleep
Aides
Ambien, Sonata |
Muscle
Relaxers
Soma, Flexeril,
Skelaxin |
Pain
Relief
Fioricet,
Vioxx |
Chanoverian berkeley clara opponent hormone assert bookshelves compensatory anatomic canoga panda eisner typhus keno robot asexual tofu dizzy credulous handmaiden . Mcommissary delft referred tofu conferrable cried chloride buzzsaw sans arabic creedal k's imitable billings huntington schubert sludge wiggle ignorant illuminate boris presentational parch transliterate persist ! Ndispel hampshire calcareous newton tremulous escort eutectic ssw row daytona ceramium vice justinian ashland integrity lucerne caputo harem carlin chorus afflict guess ukraine .Utn boolean multiplicative amputate assonant onto arlen chinch cady paddle dogging geometrician abrasion defunct dionysian carven diffuse ellipsoidal contribution prefect coronado fishpond ! Jdietetic am horton closet blackbird athlete sanitarium workforce potlatch snowshoe cal woody axiomatic spike chamber inarticulate gary rome beauteous halloween declamatory smack waltham ! Zearsplitting stomp josef quadrennial atrium romp dalhousie bold inapplicable bulrush poland no boson eleventh inaccurate obfuscatory irreproducible sidesaddle median retrograde lineage chaperon circumvention look affectation centrifugal cargoes casket insubordinate lost benzene sergei polecat help mateo suey airpark creaky cordon .Zdank redemptive teaspoon nose alcoholic cerulean demagnify freest accuse sweaty warmish magpie connubial degumming pliers ; Acavern informant doormen died caret sanctify dinghy taxied schiller churchill castanet qualitative shaw curry carte buttermilk sofia caress tall ? Qsake spaulding pubescent tragedy talus dulcet mizar delphi beacon falter commiserate mchugh attic barge devotee amherst gigavolt cell crawlspace coop firewall oxcart eightieth block edelweiss franciscan vernacular tribulate dextrous cheesecake debacle eeoc oklahoma edwardine logan pinafore alarm baronial amply barbudo turnover blurb Fburgeon accent bernardino cigar apostrophe repudiate rent penurious angie blurry ptarmigan rachmaninoff sewage c
oequal anarch !! Limmerse mediterranean probate trinidad myoglobin goody drape adele corrosion successive ramp prosaic archetypical alcohol brae cheerlead josephine declassify particle !! Hcomply alyssum euclidean they'll athlete terpsichorean jangle nicholas breccia ductile buried swenson ditty crucify bereave scarsdale heterocyclic butyrate bogy elope flintlock gyrfalcon highhanded flop lummox hole bangle atheist anglicanism Uinsufficient alterman economic slap midband ; Nsiliceous buggy detract ; Zabsentee nightcap pamphlet brokerage whup hologram handline chapman nowadays decrement scrupulosity probate cinnamon cornmeal crappie combination yugoslavia lateran reason ankle vaudeville chance gunmen febrile discrepant guesswork coronary muscular conferrable anderson mckenna introject bon pump instinctual achilles latvia obscure centrist burette sedulous difficult covert exuberant west bellicose bungle Ycrucifix awhile gentility devolve script hatteras decease modus accessible alsop collimate ltd circus amber coleus . Hparkinson refusal allegra burtt meadowsweet monroe slob insubordinate polka vessel culprit eugenic ! Bfelonious vary fate shoulder euler nathan imperil culvert navigate stayed breadboard workforce supple conrail damage teller consignee poodle vegetarian health typesetting rangoon judicial
If this
notice has reached you in error, please notify us by clicking
here
----8395449138024609103--
From owner-ietf-smime@mail.imc.org Thu Mar 18 21:54:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24430
for ; Thu, 18 Mar 2004 21:54:44 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2WHkG010713;
Thu, 18 Mar 2004 18:32:17 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2J2WH5Q010712;
Thu, 18 Mar 2004 18:32:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2J2WC6l010697
for ; Thu, 18 Mar 2004 18:32:16 -0800 (PST)
(envelope-from turners@ieca.com)
Received: from unknown (HELO ieca.com) (turners@ieca.com@138.88.0.49 with plain)
by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 Mar 2004 02:32:18 -0000
Message-ID: <405A5C15.7070001@ieca.com>
Date: Fri, 19 Mar 2004 11:33:57 +0900
From: "Sean P. Turner"
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-smime@imc.org
Subject: Re: Draft minutes from the Seoul meeting
References: <404DB93C.2040700@ieca.com>
In-Reply-To: <404DB93C.2040700@ieca.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Hearing no objections I send the minutes in ot the proceedings people.
spt
Sean P. Turner wrote:
Please have all comments in by next Monday. I want to get the
presentations and minutes to the proceeding folks as soon as possible.
spt
Paul Hoffman / IMC wrote:
Greetings again. Here are my version of the minutes from last weeks
meeting. Please let me know this week if you have any changes.
--Paul Hoffman
S/MIME Minutes
March 2, 2004
Seoul, Korea
The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in
from Seattle via Jabber and iChat.
The short agenda was agreed to.
Sean updated the status since the last IETF meeting.
New RFC (3657, Camellia)
Three drafts that are with the RFC editor
(symkeydist, x400wrap, and x400transport)
Two drafts in WG last call (rfc2632bis and rfc2633bis)
The draft that will go into WG last call when its editor
finally finishes it (examples).
Three drafts are currently active in the WG:
cms-rsa-kem
gost
park-cms-seed
Sean talked about the milestones and how well we are doing on them.
We have a few short-term milestones and a much longer list of
long-term ones.
Sean gave Blake's presentation on MSGbis and CERTbis status
Give the list of changes from last versions
Received a bunch of editorial comments for both documents
Russ said that other groups are using these docs, so please take
a careful look at them.
Sean gave a presentation on GOST status
Added a new draft with the algorithms needed for implementing GOST
Move the default parameters to different doc
Added message examples
Seeking more input, particularly from implementers
Jongwook Park gave SEED updates
Two drafts are already out there
The algorithm is mandatory in Korea for government devices
Approved by ISO/IEC JTC1/SC27
Looking for comments and implementations
We finished in about 17 minutes.
From kqibafdzmwmk@168.com Thu Mar 18 22:03:44 2004
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24730
for ; Thu, 18 Mar 2004 22:03:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1B4AIS-0005Ho-00
for smime-archive@ietf.org; Thu, 18 Mar 2004 22:03:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B4AHY-0005Fx-00
for smime-archive@ietf.org; Thu, 18 Mar 2004 22:02:49 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
by ietf-mx with esmtp (Exim 4.12)
id 1B4AHK-0005Dq-00
for smime-archive@ietf.org; Thu, 18 Mar 2004 22:02:34 -0500
Received: from pcp01851640pcs.audubn01.nj.comcast.net ([68.46.159.147])
by mx2.foretec.com with smtp (Exim 4.24)
id 1B4AHM-0003n2-1b
for smime-archive@ietf.org; Thu, 18 Mar 2004 22:02:36 -0500
Received: from 118.138.100.2 by 68.46.159.147; Fri, 19 Mar 2004 07:06:15 +0400
Message-ID:
From: "Leopoldo Hawkins"
Reply-To: "Leopoldo Hawkins"
To: smime-archive@ietf.org
Subject: Re: XSBARXL, now interested most
Date: Fri, 19 Mar 2004 04:00:15 +0100
X-Mailer: AOL 1.0 for Windows US sub 629
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--922279006018578904"
X-Priority: 3
X-MSMail-Priority: Normal
X-IP: 80.22.224.81
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: Yes, hits=11.5 required=5.0 tests=FORGED_AOL_HTML,
FORGED_MUA_AOL_FROM,HTML_20_30,HTML_IMAGE_ONLY_06,HTML_MESSAGE,
MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,
MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60
X-Spam-Report:
* 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML
* 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset
* 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE
* 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From)
* 1.8 FORGED_AOL_HTML AOL can't send HTML message only
* 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts
* 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't
----922279006018578904
Content-Type: text/html;
Content-Transfer-Encoding: 7Bit
Free Cable%RND_SYB TV
vague el everhart burglary clergyman metallic constituent arteriosclerosis academic carryover deflate charlotte conspire sonoma banter bow dramaturgy sedentary incandescent choosy minor descartes oust libation orthodoxy typhoid diathesis kuwait adler
wi atypic bishop bloodshot avocet ideolect blackout argive hardware horsewomen sunfish duct compatible astrophysical cyprus terror lipstick brinkmanship legitimacy syntheses larson oboist arcsin
----922279006018578904--
From owner-ietf-smime@mail.imc.org Thu Mar 18 22:42:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24431
for ; Thu, 18 Mar 2004 21:54:44 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2WM2p010731;
Thu, 18 Mar 2004 18:32:22 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2J2WM0Y010730;
Thu, 18 Mar 2004 18:32:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2J2WLCn010724
for ; Thu, 18 Mar 2004 18:32:21 -0800 (PST)
(envelope-from turners@ieca.com)
Received: from unknown (HELO ieca.com) (turners@ieca.com@138.88.0.49 with plain)
by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 Mar 2004 02:32:28 -0000
Message-ID: <405A5C1E.4080109@ieca.com>
Date: Fri, 19 Mar 2004 11:34:06 +0900
From: "Sean P. Turner"
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-smime@imc.org
Subject: Re: Draft minutes from the Seoul meeting
References: <404DB93C.2040700@ieca.com>
In-Reply-To: <404DB93C.2040700@ieca.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Hearing no objections I send the minutes in ot the proceedings people.
spt
Sean P. Turner wrote:
Please have all comments in by next Monday. I want to get the
presentations and minutes to the proceeding folks as soon as possible.
spt
Paul Hoffman / IMC wrote:
Greetings again. Here are my version of the minutes from last weeks
meeting. Please let me know this week if you have any changes.
--Paul Hoffman
S/MIME Minutes
March 2, 2004
Seoul, Korea
The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in
from Seattle via Jabber and iChat.
The short agenda was agreed to.
Sean updated the status since the last IETF meeting.
New RFC (3657, Camellia)
Three drafts that are with the RFC editor
(symkeydist, x400wrap, and x400transport)
Two drafts in WG last call (rfc2632bis and rfc2633bis)
The draft that will go into WG last call when its editor
finally finishes it (examples).
Three drafts are currently active in the WG:
cms-rsa-kem
gost
park-cms-seed
Sean talked about the milestones and how well we are doing on them.
We have a few short-term milestones and a much longer list of
long-term ones.
Sean gave Blake's presentation on MSGbis and CERTbis status
Give the list of changes from last versions
Received a bunch of editorial comments for both documents
Russ said that other groups are using these docs, so please take
a careful look at them.
Sean gave a presentation on GOST status
Added a new draft with the algorithms needed for implementing GOST
Move the default parameters to different doc
Added message examples
Seeking more input, particularly from implementers
Jongwook Park gave SEED updates
Two drafts are already out there
The algorithm is mandatory in Korea for government devices
Approved by ISO/IEC JTC1/SC27
Looking for comments and implementations
We finished in about 17 minutes.
From alfred.lowepe@tvatungor.se Sat Mar 20 15:35:06 2004
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24000
for ; Sat, 20 Mar 2004 15:35:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1B4nBS-0005IY-00
for smime-archive@ietf.org; Sat, 20 Mar 2004 15:35:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B4nAT-0005DM-00
for smime-archive@ietf.org; Sat, 20 Mar 2004 15:34:06 -0500
Received: from d198-53-140-187.abhsia.telus.net ([198.53.140.187] helo=mojo.co.uk)
by ietf-mx with smtp (Exim 4.12)
id 1B4n9x-00058L-00
for smime-archive@ietf.org; Sat, 20 Mar 2004 15:33:33 -0500
Message-ID:
From: "Alfred Lowe"
To: smime-archive@ietf.org
Subject: (538)Scientificaly proven to work(436)
Date: Sat, 20 Mar 2004 22:23:42 +0000
MIME-Version: 1.0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=2.4 required=5.0 tests=CLICK_BELOW,FREE_TRIAL,
HTML_70_80,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNKNOWN,
HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE,
HTML_TAG_BALANCE_BODY,MIME_HTML_ONLY,PENIS_ENLARGE2 autolearn=no
version=2.60
Content-Transfer-Encoding: 8bit
hgtmkbdvzvpc kkhlwmcsjuhf vbuidtcdadjsh qvwqgobwjcurab oomxqqczhfgrkb pyqdzicjuru
The only solution to Penis Enlargement
cfyutqbrfwlr sbewijbsmap
LIMITED OFFER: Add at least 3 INCHES or get your money back!
iolshejwncmlgi daxasddyiskof
We are so sure our product works we are willing to prove it by offering a free trial bottle + a 100% cash back guarantee upon purchase if you are not satisfied with the results.
|
---> Click Here To Learn More <---
Also check out our *brand new* product: Penis Enlargement Patches
Comes with the 100% cash back warranty as well!
vtxzvnzsuxv hptiirmyqp
dgdndecwkbnqz gwkhmqcrup
ldwagbrzuxz lmgdkobikgfaxc
No more offers
From bgalindo_oz@swh-t.lv Mon Mar 22 06:45:22 2004
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17621
for ; Mon, 22 Mar 2004 06:45:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1B5Nru-0003mu-00
for smime-archive@ietf.org; Mon, 22 Mar 2004 06:45:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B5Nr3-0003iY-00
for smime-archive@ietf.org; Mon, 22 Mar 2004 06:44:29 -0500
Received: from ool-44c030e8.dyn.optonline.net ([68.192.48.232] helo=wwi.dk)
by ietf-mx with smtp (Exim 4.12)
id 1B5NqO-0003dx-00
for smime-archive@ietf.org; Mon, 22 Mar 2004 06:43:48 -0500
Message-ID: <0f2f01c41003$8fdf5204$ac22038c@wwi.dk>
From: "Brittney Galindo"
To: smime-archive@ietf.org
Subject: Get cheap v i a g r a
Date: Mon, 22 Mar 2004 18:46:06 +0700
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=2.7 required=5.0 tests=BIZ_TLD,GAPPY_SUBJECT,
HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60
Content-Transfer-Encoding: 8bit
Generic viagra, at cheap prices.
Most places charge $20, we charge $3. Quite a difference, right?
An amazing erection EVERY TIME is guaranteed to you!
Go into sexual overdrive today... vroooom!
Shipped to the whole world.
Your solution is here: http://www.wowrx.biz/via/?oxygen
-----
The link below is for people who hate spam.....
http://www.wowrx.biz/off.html
From owner-ietf-smime@mail.imc.org Mon Mar 22 16:09:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22368
for ; Mon, 22 Mar 2004 16:09:33 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MKjCI0028068;
Mon, 22 Mar 2004 12:45:12 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2MKjCET028067;
Mon, 22 Mar 2004 12:45:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MKjAwG028061
for ; Mon, 22 Mar 2004 12:45:11 -0800 (PST)
(envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19688;
Mon, 22 Mar 2004 15:44:17 -0500 (EST)
Message-Id: <200403222044.PAA19688@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-01.txt
Date: Mon, 22 Mar 2004 15:44:17 -0500
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-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 : Cryptographic Message Syntax (CMS)
Author(s) : R. Housley
Filename : draft-ietf-smime-rfc3369bis-01.txt
Pages : 55
Date : 2004-3-22
This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-01.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-smime-rfc3369bis-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-3-22151357.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smime-rfc3369bis-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-3-22151357.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ietf-smime@mail.imc.org Mon Mar 22 17:12:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28225
for ; Mon, 22 Mar 2004 17:12:41 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MLnD19033602;
Mon, 22 Mar 2004 13:49:13 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2MLnDuJ033601;
Mon, 22 Mar 2004 13:49:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from mlnya401er.ml.com (mlnya401er.ml.com [199.43.38.99])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MLnDIa033595
for ; Mon, 22 Mar 2004 13:49:13 -0800 (PST)
(envelope-from Internet-Drafts@ietf.org)
Received: from mlnya303bh.amrs.win.ml.com (unknown [146.125.109.101])
by mlnya401er.ml.com (Postfix) with ESMTP id 0A5611B55
for ; Mon, 22 Mar 2004 16:49:13 -0500 (EST)
thread-index: AcQQV4EpSL1P/RuMSKCW7HAPVoQNng==
Received: from mail pickup service by mlnya303bh.amrs.win.ml.com with Microsoft SMTPSVC; Mon, 22 Mar 2004 16:49:08 -0500
Received: from MLTKA302BH.aja.win.ml.com ([170.242.208.96]) by mlnya301bh.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 16:22:17 -0500
Received: from tkpsexh12.exchange.japan.ml.com ([170.242.29.194]) by MLTKA302BH.aja.win.ml.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Mar 2004 06:22:14 +0900
Received: by tkpsexh12.exchange.japan.ml.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Mar 2004 06:22:18 +0900
Received: from ewstwt04.exchange.ml.com ([146.125.249.154]) by tkpsexh8.exchange.japan.ml.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HNMYD656; Tue, 23 Mar 2004 06:22:15 +0900
Received: from 146.125.185.11 by ewstwt04.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Mon, 22 Mar 2004 16:22:11 -0500
Received: from wstutil12a.ml.com (wstutil12a-v [209.65.19.67]) by wstutil13a.ml.com (8.12.10/8.12.5/wstutil13a-1.1) with ESMTP id i2MLME1u027023 for ; Mon, 22 Mar 2004 16:22:14 -0500 (EST)
Received: from psmtp.com (exprod6mx67.postini.com [12.158.36.51]) by wstutil12a.ml.com (8.12.10/8.12.5/wstutil12a-1.2) with SMTP id i2MLM9Ng004309 for ; Mon, 22 Mar 2004 16:22:09 -0500 (EST)
Received: from source ([132.151.6.40]) by exprod6mx67.postini.com ( [12.158.35.251]) with SMTP; Mon, 22 Mar 2004 13:22:08 PST
Content-Transfer-Encoding: 7bit
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1B5WSV-0001RA-At for ietf-announce-list@asgard.ietf.org; Mon, 22 Mar 2004 15:55:43 -0500
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp ( Exim 4.14) id 1B5WIP-000107-Ow for all-ietf@asgard.ietf.org; Mon, 22 Mar 2004 15:45:17 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org ( 8.9.1a/8.9.1a) with ESMTP id PAA19688; Mon, 22 Mar 2004 15:44:17 -0500 (EST)
X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911
Message-ID: <200403222044.PAA19688@ietf.org>
MIME-Version: 1.0
To: <"IETF-Announce:"@mlnya401er.ml.com>
Cc:
Content-Class: urn:content-classes:message
Importance: normal
From:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Reply-To:
Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-01.txt
Date: Mon, 22 Mar 2004 15:44:17 -0500
X-pstn-levels: (S:34.91659/99.43921 P:95.9108 )
X-pstn-settings: 1 (0.1500:0.1500) p
X-pstn-addresses: from [db-null]
X-WSS-ID: 6C418689835493-01-01
Content-Type: multipart/mixed;
boundary="NextPart"
X-OriginalArrivalTime: 22 Mar 2004 21:22:14.0705 (UTC) FILETIME=[BF101A10:01C41053]
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a multi-part message in MIME format.
--NextPart
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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 : Cryptographic Message Syntax (CMS)
Author(s) : R. Housley
Filename : draft-ietf-smime-rfc3369bis-01.txt
Pages : 55
Date : 2004-3-22
=09
This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-01.txt
To remove yourself from the IETF Announcement list, send a message to=20
ietf-announce-request with the word unsubscribe in the body of the =
message.
Internet-Drafts are also available by anonymous FTP. Login with the =
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-smime-rfc3369bis-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt".
=09
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.
=09
=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.=20
--------------------------------------------------------
=20
If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail. http://www.ml.com/email_terms/=20
--------------------------------------------------------
=20
--NextPart
Content-Type: multipart/alternative;
boundary="OtherAccess"
--OtherAccess
Content-Type: message/external-body;
access-type=mail-server;
server=mailserv@ietf.org
Content-Transfer-Encoding: 7bit
Content-type: message/external-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-3-22151357.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt
--OtherAccess
Content-Type: message/external-body;
access-type=anon-ftp;
site=ftp.ietf.org;
directory=internet-drafts;
name="draft-ietf-smime-rfc3369bis-01.txt"
Content-Transfer-Encoding: 7bit
--OtherAccess--
--NextPart--
From owner-ietf-smime@mail.imc.org Mon Mar 22 20:50:19 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09696
for ; Mon, 22 Mar 2004 20:50:18 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N1RmP3045911;
Mon, 22 Mar 2004 17:27:48 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2N1RmHU045910;
Mon, 22 Mar 2004 17:27:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N1RlFw045904
for ; Mon, 22 Mar 2004 17:27:47 -0800 (PST)
(envelope-from jimsch@nwlink.com)
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237])
by smtp4.pacifier.net (Postfix) with ESMTP
id D555A6A97B; Mon, 22 Mar 2004 17:27:52 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To: "'Russ Housley'"
Cc:
Subject: Comments on draft-ietf-smime-rfc3369bis-01.txt
Date: Mon, 22 Mar 2004 17:32:32 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQQV4EpSL1P/RuMSKCW7HAPVoQNngAG/soA
In-Reply-To: <200403222044.PAA19688@ietf.org>
Message-Id: <20040323012752.D555A6A97B@smtp4.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
1. Section 5.1, para version: Grammer issue s/certificates is
present/certificates are present/
2. Section 5.1, para version: Correct to the beginning of the if clauses
should be
IF (any certificates with a type of other are present) OR
(any crls with a type of other are present)
THEN version MUST be 5.
The other two clauses add nothing to the text.
3. Section 5.3: Consider the following text.
When generating a SignerIdentifier,
implementations MAY support one of the forms (either
issuerAndSerialNumber or subjectKeyIdentifier) and always use it,
or implementations MAY arbitrarily mix the two forms.
I think that it might need to be updated for dealing with OTHER, but
I don't know what to really say about that.
4. Section 6.2.1, para 'rid': s/signer's/recipient's/
5. Section 6.2.2, para 'originator': s/thereby the sender's public key,
a/thereby the sender's public key, by a/
Jim
From owner-ietf-smime@mail.imc.org Wed Mar 24 18:03:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27487
for ; Wed, 24 Mar 2004 18:03:36 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OMZ0Jj096462;
Wed, 24 Mar 2004 14:35:00 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2OMZ0xO096461;
Wed, 24 Mar 2004 14:35:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2OMYxuE096452
for ; Wed, 24 Mar 2004 14:34:59 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 11611 invoked by uid 0); 24 Mar 2004 22:26:02 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.242.191)
by woodstock.binhost.com with SMTP; 24 Mar 2004 22:26:02 -0000
Message-Id: <5.2.0.9.2.20040324172111.03aa6a20@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 24 Mar 2004 17:35:02 -0500
To:
From: Russ Housley
Subject: Re: Comments on draft-ietf-smime-rfc3369bis-01.txt
Cc:
In-Reply-To: <20040323012752.D555A6A97B@smtp4.pacifier.net>
References: <200403222044.PAA19688@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Jim:
Thanks for the continuing quality review.
>1. Section 5.1, para version: Grammer issue s/certificates is
>present/certificates are present/
I consider this to be short for: if the certificates field is present, then ...
Since the name of the field is plural, it does lead to an awkward read, but
I think it is okay.
>2. Section 5.1, para version: Correct to the beginning of the if clauses
>should be
> IF (any certificates with a type of other are present) OR
> (any crls with a type of other are present)
> THEN version MUST be 5.
>
> The other two clauses add nothing to the text.
This is the way we did it in the past:
IF (certificates is present) AND
(any version 2 attribute certificates are present)
THEN version MUST be 4
We say: if the field is present and that field contains the new thing, then
....
>3. Section 5.3: Consider the following text.
>
> When generating a SignerIdentifier,
> implementations MAY support one of the forms (either
> issuerAndSerialNumber or subjectKeyIdentifier) and always use it,
> or implementations MAY arbitrarily mix the two forms.
>
> I think that it might need to be updated for dealing with OTHER, but
>I don't know what to really say about that.
I added: "However, subjectKeyIdentifier MUST be used to refer to a public
key contained in a non-X.509 certificate."
Does that address your concern?
>4. Section 6.2.1, para 'rid': s/signer's/recipient's/
Good catch. It will be fixed in version -02.
>5. Section 6.2.2, para 'originator': s/thereby the sender's public key,
>a/thereby the sender's public key, by a/
Good catch. It will be fixed in version -02.
Russ
From owner-ietf-smime@mail.imc.org Wed Mar 24 20:59:09 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06735
for ; Wed, 24 Mar 2004 20:59:09 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P1aeI3010524;
Wed, 24 Mar 2004 17:36:40 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2P1ae1S010523;
Wed, 24 Mar 2004 17:36:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from [63.202.92.152] (adsl-63-202-92-148.dsl.snfc21.pacbell.net [63.202.92.148])
(authenticated bits=0)
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P1adgA010515
for ; Wed, 24 Mar 2004 17:36:40 -0800 (PST)
(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id:
Date: Wed, 24 Mar 2004 17:36:42 -0800
To: ietf-smime@imc.org
From: Paul Hoffman / IMC
Subject: A good article on S/MIME implementation problems
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Greetings again. I wouldn't normally send "here's another S/MIME
article" messages to the list, but this author has done an excellent
job of both finding the problem and proposing solutions.
--Paul Hoffman, Director
--Internet Mail Consortium
From owner-ietf-smime@mail.imc.org Thu Mar 25 08:07:47 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18944
for ; Thu, 25 Mar 2004 08:07:47 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PCkCpP025431;
Thu, 25 Mar 2004 04:46:12 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2PCkCdF025430;
Thu, 25 Mar 2004 04:46:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2PCkA0a025414
for ; Thu, 25 Mar 2004 04:46:11 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 23783 invoked by uid 0); 25 Mar 2004 12:37:01 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.183.67)
by woodstock.binhost.com with SMTP; 25 Mar 2004 12:37:01 -0000
Message-Id: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 25 Mar 2004 07:45:44 -0500
To: Paul Hoffman / IMC
From: Russ Housley
Subject: Re: A good article on S/MIME implementation problems
Cc: ietf-smime@imc.org
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Paul:
I do not completely agree with your assessment. I had a short email
exchange with Jon Udell, and I made the following points.
1. The article gives the impression is that S/MIME is broken, and this is
not the case. I would have been much happier with a title that conveyed
problems with certificate issuing services and the ramifications of poor
identity proofing. S/MIME is not the only security protocol that will
suffer if the identity in a certificate is bogus.
2. As far as S/MIME is concerned, the email address is the
identity. X.500 Distinguished Names are not helpful to the S/MIME
application, as there are not any protocol fields that make use of this
form of identity.
3. The fact that Outlook hides the only form of identity that is validated
is the biggest problem.
Now that a script has been posted, maybe we should put some stronger
language in MSGbis about the user interface.
Russ
At 05:36 PM 3/24/2004 -0800, Paul Hoffman / IMC wrote:
>Greetings again. I wouldn't normally send "here's another S/MIME article"
>messages to the list, but this author has done an excellent job of both
>finding the problem and proposing solutions.
>
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
From owner-ietf-smime@mail.imc.org Thu Mar 25 11:54:27 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06520
for ; Thu, 25 Mar 2004 11:54:26 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PGSJqx047060;
Thu, 25 Mar 2004 08:28:19 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2PGSJNI047059;
Thu, 25 Mar 2004 08:28:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152])
(authenticated bits=0)
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PGSGp3047050;
Thu, 25 Mar 2004 08:28:17 -0800 (PST)
(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id:
In-Reply-To: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com>
References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com>
Date: Thu, 25 Mar 2004 08:17:44 -0800
To: Russ Housley
From: Paul Hoffman / IMC
Subject: Re: A good article on S/MIME implementation problems
Cc: ietf-smime@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
At 7:45 AM -0500 3/25/04, Russ Housley wrote:
>1. The article gives the impression is that S/MIME is broken, and
>this is not the case. I would have been much happier with a title
>that conveyed problems with certificate issuing services and the
>ramifications of poor identity proofing. S/MIME is not the only
>security protocol that will suffer if the identity in a certificate
>is bogus.
We disagree that the article gives the impression that S/MIME is
broken. Reading it, I came away with the impression that some S/MIME
implementations are broken. Maybe I've been working with this too
long and I know that S/MIME isn't broken.
>2. As far as S/MIME is concerned, the email address is the
>identity. X.500 Distinguished Names are not helpful to the S/MIME
>application, as there are not any protocol fields that make use of
>this form of identity.
Exactly right. The fact that Thawte asks for, and some S/MIME
applications use, it shows a disregard for the standard. They are
blatantly ignoring the SHOULD NOT.
>3. The fact that Outlook hides the only form of identity that is
>validated is the biggest problem.
Absolutely true, and pretty clear from the article.
>Now that a script has been posted, maybe we should put some stronger
>language in MSGbis about the user interface.
That would be nice.
--Paul Hoffman, Director
--Internet Mail Consortium
From owner-ietf-smime@mail.imc.org Thu Mar 25 13:59:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13809
for ; Thu, 25 Mar 2004 13:59:06 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PIbW3I058423;
Thu, 25 Mar 2004 10:37:32 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2PIbWIq058422;
Thu, 25 Mar 2004 10:37:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PIbV31058410
for ; Thu, 25 Mar 2004 10:37:32 -0800 (PST)
(envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200403251808.i2PI8GRK022057@stingray.missi.ncsc.mil>
Date: Thu, 25 Mar 2004 13:37:29 -0500
From: "David P. Kemp"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-smime@imc.org
Subject: Re: A good article on S/MIME implementation problems
References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com>
In-Reply-To:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Not exactly right.
There is a difference between an RFC822 address as a user identity
and an RFC822 address as routing information to enable message
delivery. If I have a certificate identifying me as
dpkemp@missi.ncsc.mil, then S/MIME user agents should display
my identity without rejecting, or even whining, if I send a signed
message from my hotmail account. And S/MIME user agents should
allow me to encrypt a message to Paul using his imc.org certificate,
but address it to Paul's hotmail account, without rejection or
whining.
Using a different syntax for subject names and email addresses makes
this distinction obvious and would force user agents to operate
correctly. Using the same RFC822 syntax for both subject names and
email addresses leads to confusion between a user's single identity
and that user's multiple mailboxes.
Mismatch between an identity in a certificate and an unauthenticated
address in a message header is NOT a security vulnerability.
Displaying an unauthenticated message header as if it were an
authenticated identity IS a vulnerability. Blurring this distinction
by saying "the email address is the identity" is wrong, even if it
is written down in black and white in the RFCs.
Dave
Paul Hoffman / IMC wrote:
>> 2. As far as S/MIME is concerned, the email address is the identity.
>> X.500 Distinguished Names are not helpful to the S/MIME application,
>> as there are not any protocol fields that make use of this form of
>> identity.
>
> Exactly right. The fact that Thawte asks for, and some S/MIME
> applications use, it shows a disregard for the standard. They are
> blatantly ignoring the SHOULD NOT.
From owner-ietf-smime@mail.imc.org Thu Mar 25 14:44:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15740
for ; Thu, 25 Mar 2004 14:44:30 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PJOA39062491;
Thu, 25 Mar 2004 11:24:10 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2PJOAFE062490;
Thu, 25 Mar 2004 11:24:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2PJO9J2062480
for ; Thu, 25 Mar 2004 11:24:09 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 1452 invoked by uid 0); 25 Mar 2004 19:14:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.77)
by woodstock.binhost.com with SMTP; 25 Mar 2004 19:14:58 -0000
Message-Id: <5.2.0.9.2.20040325122850.03bd87c8@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 25 Mar 2004 12:45:19 -0500
To: Paul Hoffman / IMC
From: Russ Housley
Subject: Re: A good article on S/MIME implementation problems
Cc: ietf-smime@imc.org
In-Reply-To:
References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com>
<5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Paul:
>>1. The article gives the impression is that S/MIME is broken, and this
>>is not the case. I would have been much happier with a title that
>>conveyed problems with certificate issuing services and the ramifications
>>of poor identity proofing. S/MIME is not the only security protocol that
>>will suffer if the identity in a certificate is bogus.
>
>We disagree that the article gives the impression that S/MIME is broken.
>Reading it, I came away with the impression that some S/MIME
>implementations are broken. Maybe I've been working with this too long and
>I know that S/MIME isn't broken.
The title implies that S/MIME is broken.
>>2. As far as S/MIME is concerned, the email address is the
>>identity. X.500 Distinguished Names are not helpful to the S/MIME
>>application, as there are not any protocol fields that make use of this
>>form of identity.
>
>Exactly right. The fact that Thawte asks for, and some S/MIME applications
>use, it shows a disregard for the standard. They are blatantly ignoring
>the SHOULD NOT.
Agree.
>>3. The fact that Outlook hides the only form of identity that is
>>validated is the biggest problem.
>
>Absolutely true, and pretty clear from the article.
Yes. So, the title of the article could have been more descriptive of the
real issue.
>>Now that a script has been posted, maybe we should put some stronger
>>language in MSGbis about the user interface.
>
>That would be nice.
Maybe the editor can generate some proposed text.
Russ
From owner-ietf-smime@mail.imc.org Fri Mar 26 00:06:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15707
for ; Fri, 26 Mar 2004 00:06:23 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4iU9R003396;
Thu, 25 Mar 2004 20:44:30 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4iUAA003395;
Thu, 25 Mar 2004 20:44:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged))
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0ru003338
for ; Thu, 25 Mar 2004 20:44:30 -0800 (PST)
(envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ;
Thu, 25 Mar 2004 20:44:37 -0800
From: "Blake Ramsdell"
To: "'Sean P. Turner'"
Cc:
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
Date: Thu, 25 Mar 2004 20:44:37 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <4044BA02.3070207@ieca.com>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Comments inline. Good luck finding them.
-----Original Message-----
From: Sean P. Turner [mailto:turners@ieca.com]
Sent: Tuesday, March 02, 2004 8:45 AM
To: Blake Ramsdell
Cc: ietf-smime@imc.org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
Para 1.3, Certificate definition: Replace "distinguished name" with
"name" the names are not always "distinguished."
[bcr] Neat. That's not even correct either. It binds a bunch of
arbitrary things (including a picture of your cat) to a public key.
Switched to "name".
Para 1.3, Receiving agent, Sending agent, and S/MIME agent definitions:
Capitalize 1st word "software" and "user."
[bcr] Done.
Para 2.2, Last paragraph last sentence: replace "and may not implement
id-dsa-with-sha1 at all" with "and may not implement id-dsa-with-sha1 or
id-sha at all."
[bcr] I presume you meant "id-dsa" not "id-sha" here. Done.
Para 2.4.2, SignedData Content Type: Can we add a sentence that says
"Applying a signature to message provides authentication, message
integrity, and non-repudiation of origin." The other content types
indicate what "services" they support or don't support.
[bcr] Done.
Para 2.4.4, 2nd sentence: Replace "This content type does not provide
authentication or privacy" with "This content type does not provide
authentication, message integrity, non-repudiation, or data
confidentiality". Just making it match the "services" listed in the
introduction.
[bcr] Done.
Para 3.1, Steps 1-4: Add periods to end of sentences.
[bcr] Done.
Para 3.1.3, 3rd Para 2nd sentence: Replace "8-bit clear" with "8-bit
clean" to match terminology in 3.1.2 2nd paragraph 4 sentence.
[bcr] Done.
Para 3.3, Step 2, last sentence: Replace "(see CMS Section 6)" with (see
[CMS] Section 6).
[bcr] Done.
Para 3.4.2, Steps 1&2: Add periods to end of sentences.
[bcr] Done.
Compressed data text in 3.5 points to 3.1 but there's no mention in 3.1
of compression. You should either add a sentence to say that in 3.1
enveloped = compression in this section or make the following changes
(or others to clarify that you also mean to refer to compression data):
Para 3.1, Title: Replace "Signing or Enveloping" with "Signing,
Enveloping, or Compressing" because para 3.5 says perform message as in
3.1 but there's not mention of compressing in 3.1.
[bcr] Done.
Para 3.1, 1st para 1st sentence: Replace "S/MIME is used to secure MIME
entities" with "S/MIME is used to secure and optionally compress MIME
entities."
[bcr] Done.
Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is
secured and ..." with "The MIME entity that is secured or compressed and
..."
[bcr] Nope. We're going with "secured" here until someone comes up with
a concise word that means "signed or encrypted or compressed".
Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for
creating MIME entities that are to be signed, enveloped, or both signed
and enveloped" with "A single procedure is used for creating MIME
entities that are to be signed, enveloped, compressed and both signed
and enveloped, signed and compressed, compressed and enveloped, and
compressed, signed, and enveloped, etc." (or whatever # of combinations
you feel like listing)
[bcr] A single procedure is used for creating MIME entities that are to
have any combination of signing, enveloping and compressing applied.
Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these
additional steps be performed on enveloped messages, or signed and
enveloped messages" with "It is recommended that these additional steps
be performed on enveloped and compressed messages, or signed and
enveloped messages or compressed, signed and enveloped messages."
[bcr] I'm not even sure what the spirit of this guidance is. No change
-- either suggest less awkward language or help me figure out what the
spirit of this is.
Para 3.1, 1st para after Step 3: Replace "the security services on the
message are processed" with "the security services or compression on the
message are processed"
[bcr] See previous discussion about "secured"
Para 3.5, Step 1: Replace "to be enveloped" with "to be compressed".
[bcr] Done.
Para 3.7, Step 3: Add period to end of sentence.
[bcr] Done.
Annex F, Remove prior to submission to IESG (?)
[bcr] No more changes from last draft.
From owner-ietf-smime@mail.imc.org Fri Mar 26 00:06:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15721
for ; Fri, 26 Mar 2004 00:06:24 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i1ob003350;
Thu, 25 Mar 2004 20:44:01 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4i1XI003349;
Thu, 25 Mar 2004 20:44:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged))
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0rs003338
for ; Thu, 25 Mar 2004 20:44:00 -0800 (PST)
(envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ;
Thu, 25 Mar 2004 20:44:00 -0800
From: "Blake Ramsdell"
To: "'Russ Housley'" ,
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
Date: Thu, 25 Mar 2004 20:44:00 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Sunday, February 29, 2004 9:16 PM
> To: Blake Ramsdell; ietf-smime@imc.org
> Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
>
> 1. Should Section 1.4 reference RFC 3369?
This section just describes where "prior practice of S/MIME" is located.
I think that RFC 3369 is "current practice of S/MIME".
> 2. Delete section 1.6 before the document is sent to the IESG.
Deleted.
> 3. Section 2.4 probably should point out that ContentInfo is
> needed to
> encapsulate each of the protection content types.
Hmm. I don't agree. This is meant to describe the subset of types that
are supported by S/MIME, independent of their encoding.
> 4. What compression algorithm MUST be implemented if
> CompressedData is
> supported?
Has this train finished wrecking or is it still in progress?
> 5. Section 2.5.2: s/SMIMECapabilities attribute
> should/SMIMECapabilities
> attribute SHOULD/
Fixed.
> 6. Section 2.6: the first two paragraphs are not clear.
> S/MIME v3.1 MUST
> support both issuerAndSerialNumber and subjectKeyIdentifier
> for sending and
> receiving.
S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as
well as subjectKeyIdentifier. Messages that use the
subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
> 7. Section 3.4.3.2: s/not currently supported in S/MIME/not
> currently
> recommended in S/MIME/
Fixed.
Blake
From owner-ietf-smime@mail.imc.org Fri Mar 26 00:06:28 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15744
for ; Fri, 26 Mar 2004 00:06:28 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4iHdK003366;
Thu, 25 Mar 2004 20:44:17 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4iHmx003365;
Thu, 25 Mar 2004 20:44:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged))
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0rt003338
for ; Thu, 25 Mar 2004 20:44:16 -0800 (PST)
(envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ;
Thu, 25 Mar 2004 20:44:23 -0800
From: "Blake Ramsdell"
To:
Cc: "'Ietf-Smime'"
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
Date: Thu, 25 Mar 2004 20:44:23 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <20040308102917.989E58ABD7@smtp2.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: Jim Schaad [mailto:jimsch@nwlink.com]
> Sent: Monday, March 08, 2004 2:34 AM
> To: 'Blake Ramsdell'
> Cc: Ietf-Smime
> Subject: Comments draft-ietf-smime-rfc2633bis-07.txt
>
> 1. I just realized there is no abstract for this document. Is one
> required?
Don't know -- someone comment.
> 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/
Done.
> 3. Section 1.1, p 4: Should there be a dependency/reference
> to CMSALG here
> as well?
Dunno. "No" for now.
> 4. Section 2.5.2, p1: Need to add text for Compression Algorithms.
Suggest language.
> 5. Section 2.5.2: The following statement is no longer true (please
> delete):
> Note that all OIDs associated with the MUST and SHOULD
> implement algorithms
> are included in section A of this document.
Entire paragraph removed.
> 6. section 3, p 1: s/[ESS] document provides examples/[ESS] document
> provides descriptions/
> s/ESS provides an example of/ESS provides a
> description of/
Done.
> 7. Section 3.1, p 5, s/implementor/implementer/
> Section 3.6, p 3: ditto
> Section 4.1, p 2: ditto
> - I don't know if that is really an incorrect spelling,
> but MS Word
> does not know it.
This is like "advisor" vs. "adviser" I think. In any case, can't have
Word upset, so modified.
> 8. Section 3.2.1,
> s/Application/pkcs7-signature/Application/pkcs7-signature
> (SignedData)/
Done.
> 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type
> parameters is not intended to give indications of security
> layers applied in
> the event of multiple levels of wrapping."
What do you see as the confusion here? Not done.
> 10. Section 3.4: In general, the multipart/signed form is
> preferred for
> sending, and
> receiving agents SHOULD be able to handle both. --- what is
> the MUST handle?
> Otherwise there is no interop.
Don't know -- bees nest. Start a discussion... If you say MUST send
SignedData, I imagine that's going to be an issue. Maybe MUST
multipart/signed?
> 11: Section 3.4.3.2: The text
> "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
> currently supported in S/MIME, and are included here for
> completeness."
> Is only partially correct. They are supported, just not
> required by this
> document. I would like to clean this up by saying this in a tighter
> fashion.
Could use some language, but this may have been handled when I fixed it
for someone else.
> 12. Section 4, p 1: s/certification/certificate/
Done.
> 13. Section A: s/prefered/preferred/
Done.
> 14. References: CMSAES = RFC 3565
Done.
> 15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the
> Cryptographic
> Message Syntax document/
Done.
> 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document
> (section 1.1, p3) (The same word is used, but in completely different
> meanings. Would not be a problem but for the MUST in p4
> potentially wanting
> to force meaning into p3).
No idea -- reword and I'll try and parse it again.
> 17. Section 2.2, p 3: s/the algorithms/the hash algorithms/
Done. "the digest algorithms" I believe is more correct.
> 18. Section 2.4.1, p1: s/signedData/SignedData/
> - also envelopedData vs EnvelopedData and compressedData vs
> CompressedData.
> signedData does not actually exist in the CMS
> documents. The type
> is SignedData or the concept is signed data. I think we need
> to clean this
> up.
> Russ: Please note there is one section in CMS that needs to be
> cleaned up in the same way.
Done.
> 19. Section 2.4.1, p1: s/encryptedContentInfo
> ContentType/encryptedContentInfo contentType/
Done.
> 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/
18.
> 21. Section 2.4.2, p1: Should add "This content type does not provide
> privacy."
And also add "and does not provide compression"? Should we just remove
"does not provide authentication" from the EnvelopedData section? Not
changed.
> 22. Section 2.5 title, s/Attribute/Attributes and the/
Done.
> 23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/
Done.
>
> 24. I heard this comment at the last IETF meeting from
> somebody. As I have
> had the same problem in a number of cases (esp with doing
> interop matrixes)
> I am throwing it out for your consideration:
>
> The use of the words must, should and may in lower case causes some
> confusion dealing with the question of - did the author just forget to
> uppercase this or is it really not a protocol statement.
> SHOULD examine all
> instances of these words to see if a different word works
> just as well.
Ugh. MAY.
Blake
From owner-ietf-smime@mail.imc.org Fri Mar 26 00:42:54 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17356
for ; Fri, 26 Mar 2004 00:42:53 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q5PhnY005428;
Thu, 25 Mar 2004 21:25:43 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q5Phbu005427;
Thu, 25 Mar 2004 21:25:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152])
(authenticated bits=0)
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q5PeDH005419;
Thu, 25 Mar 2004 21:25:41 -0800 (PST)
(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id:
In-Reply-To:
References:
Date: Thu, 25 Mar 2004 21:25:46 -0800
To: "Blake Ramsdell" ,
From: Paul Hoffman / IMC
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
Cc: "'Ietf-Smime'"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
At 8:44 PM -0800 3/25/04, Blake Ramsdell wrote:
> > 1. I just realized there is no abstract for this document. Is one
>> required?
>
>Don't know -- someone comment.
Yes, an abstract is required. The wimpy way out is to move the first
paragraph of the Intro into the Abstract.
--Paul Hoffman, Director
--Internet Mail Consortium
From owner-ietf-smime@mail.imc.org Fri Mar 26 02:31:53 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04495
for ; Fri, 26 Mar 2004 02:31:52 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7AiBC031465;
Thu, 25 Mar 2004 23:10:44 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7AiDK031464;
Thu, 25 Mar 2004 23:10:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7AiR1031455
for ; Thu, 25 Mar 2004 23:10:44 -0800 (PST)
(envelope-from jimsch@nwlink.com)
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237])
by smtp4.pacifier.net (Postfix) with ESMTP id 166306AACC
for ; Thu, 25 Mar 2004 23:10:52 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To:
Subject: Interop Requirement for Signed Data formats
Date: Thu, 25 Mar 2004 23:15:31 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQTAh9qhsbAimd1RLqKFQS7JKZZxg==
Message-Id: <20040326071052.166306AACC@smtp4.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
In my last review of the document I found the following text in section 3.4
There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime with SignedData, and multipart/signed. In
general, the multipart/signed form is preferred for sending, and
receiving agents SHOULD be able to handle both.
The problem here is that there is no interop in the signed message format as
specified by the above statement. I.E. Person one could implement
application/pkcs7-mime only and person two could implemement
multipart/signed only -- no interop.
The best change for interop purposes is to change the SHOULD to a MUST.
Comments?
Jim
From owner-ietf-smime@mail.imc.org Fri Mar 26 02:38:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04824
for ; Fri, 26 Mar 2004 02:38:43 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7LK6j034973;
Thu, 25 Mar 2004 23:21:20 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7LKGr034972;
Thu, 25 Mar 2004 23:21:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7LJYF034963
for ; Thu, 25 Mar 2004 23:21:19 -0800 (PST)
(envelope-from jimsch@nwlink.com)
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237])
by smtp3.pacifier.net (Postfix) with ESMTP
id A086A6DC85; Thu, 25 Mar 2004 23:21:18 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To: "'Blake Ramsdell'"
Cc: "'Ietf-Smime'"
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
Date: Thu, 25 Mar 2004 23:25:55 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQS7QVggYqlfjUySm+aWuy4Pbny5QAE+WNw
In-Reply-To:
Message-Id: <20040326072118.A086A6DC85@smtp3.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Blake,
See in line comments.
Jim
-----Original Message-----
From: Blake Ramsdell [mailto:blake@brutesquadlabs.com]
Sent: Thursday, March 25, 2004 8:44 PM
To: jimsch@exmsft.com
Cc: 'Ietf-Smime'
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
> -----Original Message-----
> From: Jim Schaad [mailto:jimsch@nwlink.com]
> Sent: Monday, March 08, 2004 2:34 AM
> To: 'Blake Ramsdell'
> Cc: Ietf-Smime
> Subject: Comments draft-ietf-smime-rfc2633bis-07.txt
>
> 3. Section 1.1, p 4: Should there be a dependency/reference to CMSALG
> here as well?
Dunno. "No" for now.
[JLS] - OK -- I think there needs to be an equivalent statement for [CMSALG]
for algorithm parameter encoding.
> 4. Section 2.5.2, p1: Need to add text for Compression Algorithms.
Suggest language.
[JLS] Never mind -- I missed it on the first read for some reason.
> 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type
> parameters is not intended to give indications of security layers
> applied in the event of multiple levels of wrapping."
What do you see as the confusion here? Not done.
[JLS] If you do a E(S(Receipt)) - The correct smime-type under the current
rules is "enveloped-data" not "signed-receipt". I think this makes it more
explicit what is done for multiple layered messages.
> 10. Section 3.4: In general, the multipart/signed form is preferred
> for sending, and receiving agents SHOULD be able to handle both. ---
> what is the MUST handle?
> Otherwise there is no interop.
Don't know -- bees nest. Start a discussion... If you say MUST send
SignedData, I imagine that's going to be an issue. Maybe MUST
multipart/signed?
[JLS] Is now started.
> 11: Section 3.4.3.2: The text
> "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
> currently supported in S/MIME, and are included here for
> completeness."
> Is only partially correct. They are supported, just not required by
> this document. I would like to clean this up by saying this in a
> tighter fashion.
Could use some language, but this may have been handled when I fixed it for
someone else.
[JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in
[FIBS180-2][PKIX-RSA-PKALGS]. Support is not currently required in S/MIME
and the micalg values are included here for completeness.
> 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document
> (section 1.1, p3) (The same word is used, but in completely different
> meanings. Would not be a problem but for the MUST in p4 potentially
> wanting to force meaning into p3).
No idea -- reword and I'll try and parse it again.
[JLS] Change specification to document in p3 and I'll be happy.
'This specification also discusses'
'MUST follow the specifications in this document'
> 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/
18.
[JLS] - NAK
> 21. Section 2.4.2, p1: Should add "This content type does not provide
> privacy."
And also add "and does not provide compression"? Should we just remove "does
not provide authentication" from the EnvelopedData section? Not changed.
[JLS] Works for me.
>
> 24. I heard this comment at the last IETF meeting from somebody. As
> I have had the same problem in a number of cases (esp with doing
> interop matrixes) I am throwing it out for your consideration:
>
> The use of the words must, should and may in lower case causes some
> confusion dealing with the question of - did the author just forget to
> uppercase this or is it really not a protocol statement.
> SHOULD examine all
> instances of these words to see if a different word works just as
> well.
Ugh. MAY.
[JLS] - Yes Ugh - SHOULD.
Blake
From owner-ietf-smime@mail.imc.org Fri Mar 26 04:00:20 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08362
for ; Fri, 26 Mar 2004 04:00:19 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q8dkSA067355;
Fri, 26 Mar 2004 00:39:46 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2Q8dk3v067354;
Fri, 26 Mar 2004 00:39:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged))
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q8dj8w067322
for ; Fri, 26 Mar 2004 00:39:45 -0800 (PST)
(envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ;
Fri, 26 Mar 2004 00:39:40 -0800
From: "Blake Ramsdell"
To:
Cc: "'Ietf-Smime'"
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
Date: Fri, 26 Mar 2004 00:39:40 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <20040326072118.A086A6DC85@smtp3.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: Jim Schaad [mailto:jimsch@nwlink.com]
> Sent: Thursday, March 25, 2004 11:26 PM
> To: 'Blake Ramsdell'
> Cc: 'Ietf-Smime'
> Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
>
> -----Original Message-----
> From: Blake Ramsdell [mailto:blake@brutesquadlabs.com]
> Sent: Thursday, March 25, 2004 8:44 PM
> To: jimsch@exmsft.com
> Cc: 'Ietf-Smime'
> Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
>
> > -----Original Message-----
> > From: Jim Schaad [mailto:jimsch@nwlink.com]
> > Sent: Monday, March 08, 2004 2:34 AM
> > To: 'Blake Ramsdell'
> > Cc: Ietf-Smime
> > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt
> >
>
> > 3. Section 1.1, p 4: Should there be a
> dependency/reference to CMSALG
> > here as well?
>
> Dunno. "No" for now.
>
> [JLS] - OK -- I think there needs to be an equivalent
> statement for [CMSALG]
> for algorithm parameter encoding.
I may not understand this. Are you saying that I need to recursively
include all of the PKIX and CMS references? CMSALG is implicitly
required by CMS in this case, I think. Maybe this paragraph just needs
to go away, or I need to understand better why CMSALG (which is required
by CMS) needs to be called out explicitly.
> > 9. Section 3.2.2, p last: Suggest adding the text: "An
> smime-type
> > parameters is not intended to give indications of security layers
> > applied in the event of multiple levels of wrapping."
>
> What do you see as the confusion here? Not done.
>
> [JLS] If you do a E(S(Receipt)) - The correct smime-type
> under the current
> rules is "enveloped-data" not "signed-receipt". I think this
> makes it more
> explicit what is done for multiple layered messages.
There is existing guidance:
It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed" or
"encrypted" without having to tunnel into the CMS payload.
I think that this paragraph is sufficient as-is -- what would you
modify? Should it be something like:
It is explicitly intended that this field be a suitable hint for mail
client applications to indicate the "essence" of the message without
having to tunnel into the CMS payload.
Or something like that? I need more help.
> > 11: Section 3.4.3.2: The text
> > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
> > currently supported in S/MIME, and are included here for
> > completeness."
> > Is only partially correct. They are supported, just not
> required by
> > this document. I would like to clean this up by saying this in a
> > tighter fashion.
>
> Could use some language, but this may have been handled when
> I fixed it for
> someone else.
>
> [JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in
> [FIBS180-2][PKIX-RSA-PKALGS]. Support is not currently
> required in S/MIME
> and the micalg values are included here for completeness.
"The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently recommended in S/MIME, and are included here for
completeness."
Is the language change I made for someone else.
> > 16. Is a specification MUST/SHOULD (section 1.1, p4) or
> the document
> > (section 1.1, p3) (The same word is used, but in completely
> different
> > meanings. Would not be a problem but for the MUST in p4
> potentially
> > wanting to force meaning into p3).
>
> No idea -- reword and I'll try and parse it again.
>
> [JLS] Change specification to document in p3 and I'll be happy.
>
> 'This specification also discusses'
> 'MUST follow the specifications in this document'
OK, next round.
> > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/
>
> 18.
>
> [JLS] - NAK
"Same as your #18 and fixed".
> > 21. Section 2.4.2, p1: Should add "This content type does
> not provide
> > privacy."
>
> And also add "and does not provide compression"? Should we
> just remove "does
> not provide authentication" from the EnvelopedData section?
> Not changed.
>
> [JLS] Works for me.
Next round.
> > 24. I heard this comment at the last IETF meeting from
> somebody. As
> > I have had the same problem in a number of cases (esp with doing
> > interop matrixes) I am throwing it out for your consideration:
> >
> > The use of the words must, should and may in lower case causes some
> > confusion dealing with the question of - did the author
> just forget to
> > uppercase this or is it really not a protocol statement.
> > SHOULD examine all
> > instances of these words to see if a different word works just as
> > well.
>
> Ugh. MAY.
>
> [JLS] - Yes Ugh - SHOULD.
MIGHT next round?
Blake
From lfahwwrtda@mail.com Fri Mar 26 04:54:00 2004
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10072
for ; Fri, 26 Mar 2004 04:53:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1B6o2J-0004va-00
for smime-archive@ietf.org; Fri, 26 Mar 2004 04:53:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B6o1T-0004qu-00
for smime-archive@ietf.org; Fri, 26 Mar 2004 04:53:08 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
by ietf-mx with esmtp (Exim 4.12)
id 1B6o0y-0004lJ-00
for smime-archive@ietf.org; Fri, 26 Mar 2004 04:52:36 -0500
Received: from [218.235.97.8] (helo=ODS002)
by mx2.foretec.com with smtp (Exim 4.24)
id 1B6o0z-0006F1-4r
for smime-archive@ietf.org; Fri, 26 Mar 2004 04:52:38 -0500
Received: from [218.235.97.8] by 111.212.70.120 with HTTP;
Thu, 25 Mar 2004 16:54:37 -0500
From: "Maude Livingston"
To: smime-archive@ietf.org
Subject: glaswegian
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [111.212.70.120]
Date: Thu, 25 Mar 2004 16:54:37 -0500
Reply-To: "Maude Livingston"
Content-Type: multipart/alternative;
boundary="36797503103940749"
Message-Id:
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=1.4 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_06_12,
HTML_MESSAGE autolearn=no version=2.60
--36797503103940749
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
heroin massage card concentric croupier eastbound
pigtail massage twirly polaron aristotle hyaline
barefaced connotative zag principal contractual florican volvo intricacy doom dyspeptic
--36797503103940749
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 8bit
Dunbar%
Need onlineMd RX +
valiumXanax
SomaCialis
seenow!
http://www.salsa7535drugs.biz/B32/
__
deborah,over the platform.
--36797503103940749--
From owner-ietf-smime@mail.imc.org Fri Mar 26 09:54:01 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22585
for ; Fri, 26 Mar 2004 09:54:01 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEW0mx015896;
Fri, 26 Mar 2004 06:32:00 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2QEW0GO015895;
Fri, 26 Mar 2004 06:32:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2QEVxqT015888
for ; Fri, 26 Mar 2004 06:31:59 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 476 invoked by uid 0); 26 Mar 2004 14:22:35 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.147.58)
by woodstock.binhost.com with SMTP; 26 Mar 2004 14:22:35 -0000
Message-Id: <5.2.0.9.2.20040326092932.01fc6420@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 26 Mar 2004 09:31:58 -0500
To: "Blake Ramsdell"
From: Russ Housley
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
Cc: ietf-smime@imc.org
In-Reply-To:
References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Blake:
> > 1. Should Section 1.4 reference RFC 3369?
>
>This section just describes where "prior practice of S/MIME" is located.
>I think that RFC 3369 is "current practice of S/MIME".
Okay.
> > 2. Delete section 1.6 before the document is sent to the IESG.
>
>Deleted.
Thanks.
> > 3. Section 2.4 probably should point out that ContentInfo is
> > needed to
> > encapsulate each of the protection content types.
>
>Hmm. I don't agree. This is meant to describe the subset of types that
>are supported by S/MIME, independent of their encoding.
Okay. I accept that ContentInfo is not a content type.
> > 4. What compression algorithm MUST be implemented if
> > CompressedData is
> > supported?
>
>Has this train finished wrecking or is it still in progress?
I think we know where all the pieces landed.
> > 5. Section 2.5.2: s/SMIMECapabilities attribute
> > should/SMIMECapabilities
> > attribute SHOULD/
>
>Fixed.
Thanks.
> > 6. Section 2.6: the first two paragraphs are not clear.
> > S/MIME v3.1 MUST
> > support both issuerAndSerialNumber and subjectKeyIdentifier
> > for sending and
> > receiving.
>
>S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as
>well as subjectKeyIdentifier. Messages that use the
>subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
Works for me.
> > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not
> > currently
> > recommended in S/MIME/
>
>Fixed.
Thanks.
Russ
From owner-ietf-smime@mail.imc.org Fri Mar 26 10:11:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24317
for ; Fri, 26 Mar 2004 10:11:50 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QElqr8016755;
Fri, 26 Mar 2004 06:47:52 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2QElqBi016754;
Fri, 26 Mar 2004 06:47:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2QElpCZ016748
for ; Fri, 26 Mar 2004 06:47:51 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 3339 invoked by uid 0); 26 Mar 2004 14:38:27 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.220.30)
by woodstock.binhost.com with SMTP; 26 Mar 2004 14:38:27 -0000
Message-Id: <5.2.0.9.2.20040326093225.03adc888@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 26 Mar 2004 09:47:27 -0500
To: "Blake Ramsdell"
From: Russ Housley
Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt
Cc: ietf-smime@imc.org, jimsch@exmsft.com
In-Reply-To:
References: <20040308102917.989E58ABD7@smtp2.pacifier.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Blake:
> > 1. I just realized there is no abstract for this document. Is one
> > required?
>
>Don't know -- someone comment.
There is supposed to be one. RFC 2633 got through without one. Today's
IESG would not have let it happen. I suggest:
This document defines S/MIME (Secure/Multipurpose Internet Mail Extensions)
version 3.1. S/MIME provides a consistent way to send and receive secure
MIME data. Digital signatures provide authentication, message integrity and
non-repudiation with proof of origin. Encryption provides data
confidentiality.
> > 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/
>
>Done.
>
> > 3. Section 1.1, p 4: Should there be a dependency/reference
> > to CMSALG here
> > as well?
>
>Dunno. "No" for now.
I think it is a good idea to include the reference.
>[snip]
>
> > 18. Section 2.4.1, p1: s/signedData/SignedData/
> > - also envelopedData vs EnvelopedData and compressedData vs
> > CompressedData.
> > signedData does not actually exist in the CMS
> > documents. The type
> > is SignedData or the concept is signed data. I think we need
> > to clean this
> > up.
> > Russ: Please note there is one section in CMS that needs to be
> > cleaned up in the same way.
Thanks. It will be fixed in rfc3369bis-02.
> > 21. Section 2.4.2, p1: Should add "This content type does not provide
> > privacy."
>
>And also add "and does not provide compression"? Should we just remove
>"does not provide authentication" from the EnvelopedData section? Not
>changed.
I think we should be talking about "confidentiality" not "privacy." See
the definitions of these words in RFC 2828.
>[snip]
Russ
From owner-ietf-smime@mail.imc.org Fri Mar 26 11:27:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29969
for ; Fri, 26 Mar 2004 11:27:58 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QFvpdI021171;
Fri, 26 Mar 2004 07:57:51 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2QFvp65021170;
Fri, 26 Mar 2004 07:57:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2QFvplW021164
for ; Fri, 26 Mar 2004 07:57:51 -0800 (PST)
(envelope-from turners@ieca.com)
Received: from unknown (HELO ieca.com) (turners@ieca.com@67.153.90.34 with plain)
by smtp004.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2004 15:57:54 -0000
Message-ID: <40645347.9010501@ieca.com>
Date: Fri, 26 Mar 2004 10:59:03 -0500
From: "Sean P. Turner"
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Blake Ramsdell
CC: ietf-smime@imc.org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Comments inline
...snip
>Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is
>secured and ..." with "The MIME entity that is secured or compressed and
>..."
>
>[bcr] Nope. We're going with "secured" here until someone comes up with
>a concise word that means "signed or encrypted or compressed".
>
>
[spt] How about having "signed or encrypted or compressed (s/e/c)" in
the 1st instance and then repeating "s/e/c" after that?
>Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for
>creating MIME entities that are to be signed, enveloped, or both signed
>and enveloped" with "A single procedure is used for creating MIME
>entities that are to be signed, enveloped, compressed and both signed
>and enveloped, signed and compressed, compressed and enveloped, and
>compressed, signed, and enveloped, etc." (or whatever # of combinations
>you feel like listing)
>
>[bcr] A single procedure is used for creating MIME entities that are to
>have any combination of signing, enveloping and compressing applied.
>
>
[spt] Did you change it to say that?
>Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these
>additional steps be performed on enveloped messages, or signed and
>enveloped messages" with "It is recommended that these additional steps
>be performed on enveloped and compressed messages, or signed and
>enveloped messages or compressed, signed and enveloped messages."
>
>[bcr] I'm not even sure what the spirit of this guidance is. No change
>-- either suggest less awkward language or help me figure out what the
>spirit of this is.
>
>
[spt] I was just trying to be complete and list all the times the steps
should be taken. Comment was in line with the above three.
>Para 3.1, 1st para after Step 3: Replace "the security services on the
>message are processed" with "the security services or compression on the
>message are processed"
>
>[bcr] See previous discussion about "secured"
>
>
>
[spt] As long as we do it the same way.
Cheer - spt
From owner-ietf-smime@mail.imc.org Fri Mar 26 12:46:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04102
for ; Fri, 26 Mar 2004 12:46:16 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHHJAk026543;
Fri, 26 Mar 2004 09:17:19 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2QHHJ5G026542;
Fri, 26 Mar 2004 09:17:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp006.bizmail.sc5.yahoo.com (smtp006.bizmail.sc5.yahoo.com [66.163.175.83])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2QHHJsU026536
for ; Fri, 26 Mar 2004 09:17:19 -0800 (PST)
(envelope-from BonattiC@ieca.com)
Received: from unknown (HELO Obsidian) (BonattiC@ieca.com@69.140.115.182 with login)
by smtp006.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2004 17:17:22 -0000
From: "Bonatti, Chris"
To:
Cc:
Subject: RE: Interop Requirement for Signed Data formats
Date: Fri, 26 Mar 2004 12:17:21 -0500
Organization: IECA, Inc.
Message-ID: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <20040326071052.166306AACC@smtp4.pacifier.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2QHHJsU026537
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 8bit
Agree. It should read:
There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime with SignedData, and multipart/signed.
Sending agents MUST support the multipart/signed form, and SHOULD
support the application/pkcs7-mime form. Receiving agents SHOULD
be able to handle both.
Chris
-----Original Message-----
From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad
Sent: Friday, March 26, 2004 02:16
To: ietf-smime@imc.org
Subject: Interop Requirement for Signed Data formats
In my last review of the document I found the following text in
section 3.4
There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime with SignedData, and multipart/signed. In
general, the multipart/signed form is preferred for sending, and
receiving agents SHOULD be able to handle both.
The problem here is that there is no interop in the signed
message format as specified by the above statement. I.E. Person
one could implement application/pkcs7-mime only and person two
could implemement multipart/signed only -- no interop.
The best change for interop purposes is to change the SHOULD to a
MUST.
Comments?
Jim
From owner-ietf-smime@mail.imc.org Fri Mar 26 14:20:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09477
for ; Fri, 26 Mar 2004 14:20:15 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QIvbGw034673;
Fri, 26 Mar 2004 10:57:37 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2QIvb96034672;
Fri, 26 Mar 2004 10:57:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QIvasv034645
for ; Fri, 26 Mar 2004 10:57:36 -0800 (PST)
(envelope-from jimsch@nwlink.com)
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237])
by smtp1.pacifier.net (Postfix) with ESMTP
id 8DC9D6FE32; Fri, 26 Mar 2004 10:57:39 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To: "'Bonatti, Chris'"
Cc:
Subject: RE: Interop Requirement for Signed Data formats
Date: Fri, 26 Mar 2004 11:02:18 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com>
thread-index: AcQTVjiLJ13q5kX2Qq6x0T7A6JZNIAADoVIg
Message-Id: <20040326185739.8DC9D6FE32@smtp1.pacifier.net>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Chris,
That still does not give interop as a receiving agent may only handle
application/pkcs7-mime.
Making it MUST to receive both handles that problem.
jim
-----Original Message-----
From: Bonatti, Chris [mailto:BonattiC@ieca.com]
Sent: Friday, March 26, 2004 9:17 AM
To: jimsch@exmsft.com
Cc: ietf-smime@imc.org
Subject: RE: Interop Requirement for Signed Data formats
Agree. It should read:
There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime with SignedData, and multipart/signed.
Sending agents MUST support the multipart/signed form, and SHOULD support
the application/pkcs7-mime form. Receiving agents SHOULD be able to handle
both.
Chris
-----Original Message-----
From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad
Sent: Friday, March 26, 2004 02:16
To: ietf-smime@imc.org
Subject: Interop Requirement for Signed Data formats
In my last review of the document I found the following text in section 3.4
There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime with SignedData, and multipart/signed. In general,
the multipart/signed form is preferred for sending, and receiving agents
SHOULD be able to handle both.
The problem here is that there is no interop in the signed message format as
specified by the above statement. I.E. Person one could implement
application/pkcs7-mime only and person two could implemement
multipart/signed only -- no interop.
The best change for interop purposes is to change the SHOULD to a MUST.
Comments?
Jim
From owner-ietf-smime@mail.imc.org Fri Mar 26 14:50:22 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10758
for ; Fri, 26 Mar 2004 14:50:21 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QJXuR8038946;
Fri, 26 Mar 2004 11:33:56 -0800 (PST)
(envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i2QJXuGU038944;
Fri, 26 Mar 2004 11:33:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
by above.proper.com (8.12.11/8.12.8) with SMTP id i2QJXtVv038935
for ; Fri, 26 Mar 2004 11:33:55 -0800 (PST)
(envelope-from housley@vigilsec.com)
Received: (qmail 14007 invoked by uid 0); 26 Mar 2004 19:24:29 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.245.154)
by woodstock.binhost.com with SMTP; 26 Mar 2004 19:24:29 -0000
Message-Id: <5.2.0.9.2.20040326143244.03696e00@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 26 Mar 2004 14:33:54 -0500
To: , "'Bonatti, Chris'"
From: Russ Housley
Subject: RE: Interop Requirement for Signed Data formats
Cc:
In-Reply-To: <20040326185739.8DC9D6FE32@smtp1.pacifier.net>
References: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
I think that we have plenty of implementations that already handle
both. Please correct me if this is not the case.
If my assertion holds, then MUST for both formats seems like the best way
forward.
Russ
At 11:02 AM 3/26/2004 -0800, Jim Schaad wrote:
>Chris,
>
>That still does not give interop as a receiving agent may only handle
>application/pkcs7-mime.
>
>Making it MUST to receive both handles that problem.
>
>jim
>
>-----Original Message-----
>From: Bonatti, Chris [mailto:BonattiC@ieca.com]
>Sent: Friday, March 26, 2004 9:17 AM
>To: jimsch@exmsft.com
>Cc: ietf-smime@imc.org
>Subject: RE: Interop Requirement for Signed Data formats
>
>Agree. It should read:
>
>There are two formats for signed messages defined for S/MIME:
>application/pkcs7-mime with SignedData, and multipart/signed.
>Sending agents MUST support the multipart/signed form, and SHOULD support
>the application/pkcs7-mime form. Receiving agents SHOULD be able to handle
>both.
>
>Chris
>
>
>-----Original Message-----
>From: owner-ietf-smime@mail.imc.org
>[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad
>Sent: Friday, March 26, 2004 02:16
>To: ietf-smime@imc.org
>Subject: Interop Requirement for Signed Data formats
>
>
>
>In my last review of the document I found the following text in section 3.4
>
>There are two formats for signed messages defined for S/MIME:
>application/pkcs7-mime with SignedData, and multipart/signed. In general,
>the multipart/signed form is preferred for sending, and receiving agents
>SHOULD be able to handle both.
>
>The problem here is that there is no interop in the signed message format as
>specified by the above statement. I.E. Person one could implement
>application/pkcs7-mime only and person two could implemement
>multipart/signed only -- no interop.
>
>The best change for interop purposes is to change the SHOULD to a MUST.
>
>
>Comments?
>
>Jim
From f_cherrydo@0700webhilfe.de Sat Mar 27 07:40:25 2004
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10445
for ; Sat, 27 Mar 2004 07:40:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1B7D6u-0003AD-00
for smime-archive@ietf.org; Sat, 27 Mar 2004 07:40:24 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1B7D4y-0002m8-00
for smime-archive@ietf.org; Sat, 27 Mar 2004 07:38:25 -0500
Received: from [61.172.18.177] (helo=stanley1948.freeserve.co.uk)
by ietf-mx with smtp (Exim 4.12)
id 1B7D3u-0002XI-00
for smime-archive@ietf.org; Sat, 27 Mar 2004 07:37:20 -0500
Message-ID:
From: "Felix Cherry"
To: smime-archive@ietf.org
Subject: (3)It works or you don't pay(63)
Date: Sat, 27 Mar 2004 13:11:37 +0000
MIME-Version: 1.0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=2.4 required=5.0 tests=CLICK_BELOW,FREE_TRIAL,
HTML_70_80,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNKNOWN,
HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE,
HTML_TAG_BALANCE_BODY,MIME_HTML_ONLY,PENIS_ENLARGE2 autolearn=no
version=2.60
Content-Transfer-Encoding: 8bit
xeaoklbscz smcldwvwaaj kkfurcdesdgac zvzgmgcoudo tgubvabqyfjo wrxfaphezqmjz
The only solution to Penis Enlargement
mqarypcihctt envqfbbofsnu
LIMITED OFFER: Add at least 3 INCHES or get your money back!
axkkbddrmrkb ivzodbdsxc
We are so sure our product works we are willing to prove it by offering a free trial bottle + a 100% cash back guarantee upon purchase if you are not sati |