Subject: Groshredw your tool fbullseyeast
Date: Sun, 22 Feb 04 03:15:26 GMT
X-Mailer: MIME-tools 5.503 (Entity 5.501)
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="_B_7.164.ACBC.980FD_EF8A"
X-Priority: 3
X-MSMail-Priority: Normal
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=14.3 required=5.0 tests=BIZ_TLD,CLICK_BELOW,
DATE_SPAMWARE_Y2K,FROM_NUM_AT_WEBMAIL,HTML_50_60,HTML_IMAGE_ONLY_02,
HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_TAG_BALANCE_BODY,
HTML_TAG_BALANCE_HTML,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,
MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,
PENIS_ENLARGE,PENIS_ENLARGE2 autolearn=no version=2.60
X-Spam-Report:
* 1.1 FROM_NUM_AT_WEBMAIL From address is webmail, but starts with a number
* 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting
* 0.6 PENIS_ENLARGE2 BODY: Information on getting larger penis/breasts
* 1.1 PENIS_ENLARGE BODY: Information on getting larger penis/breasts
* 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here"
* 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags
* 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML
* 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words
* 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
* 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE
* 0.0 CLICK_BELOW Asks you to click below
* 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
--_B_7.164.ACBC.980FD_EF8A
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
Loading please wait..... Do you want a longer penis?

Enlarge your =
penis! Instant rock hard erections! Longer lasting time!
Click Here For=
Information
Re=
move me
--_B_7.164.ACBC.980FD_EF8A--
From owner-ietf-smime@mail.imc.org Sun Feb 22 21:07: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 VAA18603
for ; Sun, 22 Feb 2004 21:07: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 i1N1RS6g051835;
Sun, 22 Feb 2004 17:27:28 -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 i1N1RSSt051834;
Sun, 22 Feb 2004 17:27:28 -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 i1N1RPMq051824
for ; Sun, 22 Feb 2004 17:27:26 -0800 (PST)
(envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ;
Sun, 22 Feb 2004 17:27:25 -0800
From: "Blake Ramsdell"
To:
Subject: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
Date: Sun, 22 Feb 2004 17:27:25 -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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
This message initiates an SMIME Working Group Last Call on the document:
Title : S/MIME Version 3.1 Message Specification
Author(s) : B. Ramsdell
Filename : draft-ietf-smime-rfc2633bis-07.txt
Pages : 31
Date : 2004-2-17
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-07.txt
The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.
Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may
be sent to the document editor.
The Last Call period will end on Monday, March 8, 2004.
Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:
1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as a Standard Track RFC
(which generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process. So, please read and comment!
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
From owner-ietf-smime@mail.imc.org Sun Feb 22 21:09: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 VAA18690
for ; Sun, 22 Feb 2004 21:09: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 i1N1VDte051982;
Sun, 22 Feb 2004 17:31: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 i1N1VDPr051981;
Sun, 22 Feb 2004 17:31:13 -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 i1N1VARC051973
for ; Sun, 22 Feb 2004 17:31:11 -0800 (PST)
(envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ;
Sun, 22 Feb 2004 17:31:11 -0800
From: "Blake Ramsdell"
To:
Subject: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
Date: Sun, 22 Feb 2004 17:31:11 -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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
This message initiates an SMIME Working Group Last Call on the document:
Title : S/MIME Version 3.1 Certificate Handling
Author(s) : B. Ramsdell
Filename : draft-ietf-smime-rfc2632bis-05.txt
Pages : 13
Date : 2004-2-17
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-05.txt
The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.
Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may
be sent to the document editor.
The Last Call period will end on Monday, March 8, 2004.
Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:
1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as a Standard Track RFC
(which generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process. So, please read and comment!
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
From owner-ietf-smime@mail.imc.org Tue Feb 24 17:56:33 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 RAA15141
for ; Tue, 24 Feb 2004 17:56:32 -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 i1OMQ3KI078202;
Tue, 24 Feb 2004 14:26: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 i1OMQ3p4078201;
Tue, 24 Feb 2004 14:26:03 -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 i1OMQ23k078194
for ; Tue, 24 Feb 2004 14:26:03 -0800 (PST)
(envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200402242159.i1OLxotW027670@stingray.missi.ncsc.mil>
Date: Tue, 24 Feb 2004 17:25:59 -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: Blake Ramsdell
CC: ietf-smime@imc.org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
References:
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
Blake,
Thanks for clarifying the requirement to support certificates
without email addresses.
Comments:
1. Section 2.3 para 4: "Agents MAY send CA certificates, that is,
certificates that are self-signed and can be considered the "root"
of other chains." This incorrectly implies that the only kind
of CA cert is the self-signed kind. Suggest "Agents MAY send
CA certificates that are self-signed and ..."
2. Section 4.4 paragraph 2: Why must sending and receiving
agents correctly handle the listed extensions only when they
appear in end-entity certificates? Suggest that sending and
receiving agents MUST correctly (i.e. in accordance with RFC 3280)
handle the basic constraints, key usage, AKI, SKI, and SAN extensions
in end-entity *and CA* certificates.
3. Section 4.4.1 paragraph 3: "Certificates SHOULD contain a
basicConstraints extension in CA certificates and SHOULD NOT contain
that extension in end entity certificates." In order to avoid
inconsistency with PKIX, change to "Certificates MUST contain a
basicConstraints extension in CA certificates and SHOULD NOT contain
that extension in end entity certificates." In other words, a
sending and receiving agent is non-compliant if it accepts
a v3 certificate without the basicConstraints extension as a CA
certificate.
Dave
Blake Ramsdell wrote:
> This message initiates an SMIME Working Group Last Call on the document:
>
> Title : S/MIME Version 3.1 Certificate Handling
> Author(s) : B. Ramsdell
> Filename : draft-ietf-smime-rfc2632bis-05.txt
> Pages : 13
> Date : 2004-2-17
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-05.txt
>
> The purpose of this WG Last Call is to ensure that the Working Group has
> achieved consensus that the document is suitable for publication as a
> Proposed Standard.
>
> Please review the document for both technical and editorial problems.
> Technical issues should be discussed on this list. Editorial issues may
> be sent to the document editor.
>
> The Last Call period will end on Monday, March 8, 2004.
>
> Upon completion of the last call, the WG chairs will take action based
> upon the consensus of the WG. Possible actions include:
>
> 1) recommending to the IETF Security Area Directors
> that the document, after possible editorial or
> other minor changes, be considered by the IESG
> for publication as a Standard Track RFC
> (which generally involves an IETF-wide Last Call); or
>
> 2) requiring that outstanding issues be adequately
> addressed prior to further action (including,
> possibly, another WG Last Call).
>
> Remember that it is our responsibility as Working Group members to
> ensure the quality of our documents and of the Internet Standards
> process. So, please read and comment!
>
> Blake
> --
> Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
>
From dktmoa@china.com Fri Feb 27 22:06:47 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 WAA13070
for ; Fri, 27 Feb 2004 22:06:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1AwuoR-0001oT-00
for smime-archive@ietf.org; Fri, 27 Feb 2004 22:06:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1AwunW-0001jL-00
for smime-archive@ietf.org; Fri, 27 Feb 2004 22:05:51 -0500
Received: from docs1-189.menta.net ([62.57.0.189])
by ietf-mx with smtp (Exim 4.12)
id 1Awumx-0001dJ-00
for smime-archive@ietf.org; Fri, 27 Feb 2004 22:05:17 -0500
Received: from [62.57.0.189] by 24.246.208.148 with HTTP;
Sat, 28 Feb 2004 02:02:12 -0100
From: "Marshall Coffman"
To: smime-archive@ietf.org
Subject: Re: KKL, after the master
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [24.246.208.148]
Date: Fri, 27 Feb 2004 22:00:12 -0500
Reply-To: "Coffman Marshall"
Content-Type: multipart/alternative;
boundary="--ALT--UZZV13444563714143"
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=5.0 required=5.0 tests=CHINA_HEADER,HTML_20_30,
HTML_IMAGE_ONLY_06,HTML_MESSAGE autolearn=no version=2.60
----ALT--UZZV13444563714143
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
dialectic bayberry monmouth hemispheric hull broaden antioch smart
magazine configure himalaya interpolate
britches affiance coastal marathon
----ALT--UZZV13444563714143
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 8bit
Free Cable# TV
integrable starve culprit chimera laurentian andrew prelude determinant pupal sextuple digging caste nozzle bam flanders bulge chuckle hothead conferrable protease caustic contemptuous tootle chuckwalla westerly wretch passband chalk agreeable
curia monash plaster aboveground speedometer sinistral mccluskey semitic groggy candace bowfin typo cyclic mammoth wilson rawhide ppm winnie
----ALT--UZZV13444563714143--
From fzvdjhhqrhupvc@hongkong.com Sat Feb 28 06:32:10 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 GAA13238
for ; Sat, 28 Feb 2004 06:32:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1Ax2hX-0001Nt-00
for smime-archive@ietf.org; Sat, 28 Feb 2004 06:32:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1Ax2gh-0001H0-00
for smime-archive@ietf.org; Sat, 28 Feb 2004 06:31:20 -0500
Received: from [61.3.252.201] (helo=132.151.6.1)
by ietf-mx with smtp (Exim 4.12)
id 1Ax2fs-00019Y-00
for smime-archive@ietf.org; Sat, 28 Feb 2004 06:30:29 -0500
Received: from [61.3.252.201] by 164.145.180.193 with HTTP;
Sat, 28 Feb 2004 01:31:05 +0200
From: "Ismael Edmonds"
To: smime-archive@ietf.org
Subject: Re: GTJGDDJ, began pouring down
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [240.76.39.211]
Date: Fri, 27 Feb 2004 19:32:05 -0400
Reply-To: "Edmonds Ismael"
Content-Type: multipart/alternative;
boundary="--ALT--TDQK89942822059245"
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.2 required=5.0 tests=HTML_IMAGE_ONLY_08,
HTML_MESSAGE,RCVD_NUMERIC_HELO autolearn=no version=2.60
----ALT--TDQK89942822059245
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
paddy psychiatry write azimuthal freddie dacca today'll
fiddlestick ordinance signpost loam cuttlebone ontology tonic scriptural coeditor
indulge hattiesburg jacobian downstream
----ALT--TDQK89942822059245
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 8bit
Free Cable%RND_SYB TV
circumvention sell pollock bateau astronomer oilcloth prominent camelback assign antisemitic reave ascribe seamen pip rembrandt o'dell sliver sear compline modish veteran slurp wail cereus committeewomen definite cord basal assimilable avaricious leroy impulsive arsenal pinnate
crosshatch freud debility fourteenth obsess destroy decision smack cauliflower hudson revet committal marjorie octogenarian ephraim alfonso cataclysm diagrammatic rather bey report driscoll portland pail bertha defocus finessing bronchiole
----ALT--TDQK89942822059245--
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 i217ejGM032071; Sun, 29 Feb 2004 23:40: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 i217ejpn032068; Sun, 29 Feb 2004 23:40:45 -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 i217eiXY032045 for ; Sun, 29 Feb 2004 23:40:44 -0800 (PST) (envelope-from housley@vigilsec.com)
Received: (qmail 22075 invoked by uid 0); 1 Mar 2004 07:37:21 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 07:37:21 -0000
Message-Id: <5.2.0.9.2.20040301023919.03e628a8@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 01 Mar 2004 02:40:38 -0500
To: blake@brutesquadlabs.com, ietf-smime@imc.org
From: Russ Housley
Subject: Fwd: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
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:
Ooops. Please excuse the typo in #3. It should read:
3. Section 1.4: s/MD2 use for certificate signatures discouraged/The use
of the MD2 message digest for certificate signatures is discouraged/
Russ
>Date: Sun, 29 Feb 2004 23:45:49 -0500
>To: "Blake Ramsdell" ,
>From: Russ Housley
>Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
>
>I have six comments. None of them are show stoppers.
>
>1. Section 1,1, 1st sentence: s/draft/document/
>
>2. Should Section 1,2 reference RFC 3369?
>
>3. Section 1.4: s/MD2 use for certificate signatures discouraged/The use
>of the MD5 message digest for certificate signatures is discouraged/
>
>4. Delete Section 1.5 before submitting the document to the IESG.
>
>5. Section 4.4.2 include the following paragraph:
>
> If the key usage extension is not specified, receiving clients MUST
> presume that the digitalSignature and nonRepudiation bits are set.
>
>Should there be an 'only' in this sentence?
>
>6. Section 4.4.4, 2nd paragraph, last sentence. Add a period.
>
>Russ
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 i215GQlL087936; Sun, 29 Feb 2004 21:16:26 -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 i215GP8N087935; Sun, 29 Feb 2004 21:16:25 -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 i215GOL7087929 for ; Sun, 29 Feb 2004 21:16:25 -0800 (PST) (envelope-from housley@vigilsec.com)
Received: (qmail 24615 invoked by uid 0); 1 Mar 2004 05:13:11 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 05:13:11 -0000
Message-Id: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 01 Mar 2004 00:16:27 -0500
To: "Blake Ramsdell" ,
From: Russ Housley
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
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:
Hare are seven comments. I think number 6 is the most significant one, but
none of them are show stoppers.
1. Should Section 1.4 reference RFC 3369?
2. Delete section 1.6 before the document is sent to the IESG.
3. Section 2.4 probably should point out that ContentInfo is needed to
encapsulate each of the protection content types.
4. What compression algorithm MUST be implemented if CompressedData is
supported?
5. Section 2.5.2: s/SMIMECapabilities attribute should/SMIMECapabilities
attribute SHOULD/
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.
7. Section 3.4.3.2: s/not currently supported in S/MIME/not currently
recommended in S/MIME/
Russ
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 i214jngA086558; Sun, 29 Feb 2004 20:45:50 -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 i214jnX0086556; Sun, 29 Feb 2004 20:45:49 -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 i214jmhp086550 for ; Sun, 29 Feb 2004 20:45:48 -0800 (PST) (envelope-from housley@vigilsec.com)
Received: (qmail 18396 invoked by uid 0); 1 Mar 2004 04:42:34 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 04:42:34 -0000
Message-Id: <5.2.0.9.2.20040229232208.03e787f0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sun, 29 Feb 2004 23:45:49 -0500
To: "Blake Ramsdell" ,
From: Russ Housley
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
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:
I have six comments. None of them are show stoppers.
1. Section 1,1, 1st sentence: s/draft/document/
2. Should Section 1,2 reference RFC 3369?
3. Section 1.4: s/MD2 use for certificate signatures discouraged/The use
of the MD5 message digest for certificate signatures is discouraged/
4. Delete Section 1.5 before submitting the document to the IESG.
5. Section 4.4.2 include the following paragraph:
If the key usage extension is not specified, receiving clients MUST
presume that the digitalSignature and nonRepudiation bits are set.
Should there be an 'only' in this sentence?
6. Section 4.4.4, 2nd paragraph, last sentence. Add a period.
Russ
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 i1OMQ3KI078202; Tue, 24 Feb 2004 14:26: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 i1OMQ3p4078201; Tue, 24 Feb 2004 14:26:03 -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 i1OMQ23k078194 for ; Tue, 24 Feb 2004 14:26:03 -0800 (PST) (envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200402242159.i1OLxotW027670@stingray.missi.ncsc.mil>
Date: Tue, 24 Feb 2004 17:25:59 -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: Blake Ramsdell
CC: ietf-smime@imc.org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
References:
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:
Blake,
Thanks for clarifying the requirement to support certificates
without email addresses.
Comments:
1. Section 2.3 para 4: "Agents MAY send CA certificates, that is,
certificates that are self-signed and can be considered the "root"
of other chains." This incorrectly implies that the only kind
of CA cert is the self-signed kind. Suggest "Agents MAY send
CA certificates that are self-signed and ..."
2. Section 4.4 paragraph 2: Why must sending and receiving
agents correctly handle the listed extensions only when they
appear in end-entity certificates? Suggest that sending and
receiving agents MUST correctly (i.e. in accordance with RFC 3280)
handle the basic constraints, key usage, AKI, SKI, and SAN extensions
in end-entity *and CA* certificates.
3. Section 4.4.1 paragraph 3: "Certificates SHOULD contain a
basicConstraints extension in CA certificates and SHOULD NOT contain
that extension in end entity certificates." In order to avoid
inconsistency with PKIX, change to "Certificates MUST contain a
basicConstraints extension in CA certificates and SHOULD NOT contain
that extension in end entity certificates." In other words, a
sending and receiving agent is non-compliant if it accepts
a v3 certificate without the basicConstraints extension as a CA
certificate.
Dave
Blake Ramsdell wrote:
> This message initiates an SMIME Working Group Last Call on the document:
>
> Title : S/MIME Version 3.1 Certificate Handling
> Author(s) : B. Ramsdell
> Filename : draft-ietf-smime-rfc2632bis-05.txt
> Pages : 13
> Date : 2004-2-17
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-05.txt
>
> The purpose of this WG Last Call is to ensure that the Working Group has
> achieved consensus that the document is suitable for publication as a
> Proposed Standard.
>
> Please review the document for both technical and editorial problems.
> Technical issues should be discussed on this list. Editorial issues may
> be sent to the document editor.
>
> The Last Call period will end on Monday, March 8, 2004.
>
> Upon completion of the last call, the WG chairs will take action based
> upon the consensus of the WG. Possible actions include:
>
> 1) recommending to the IETF Security Area Directors
> that the document, after possible editorial or
> other minor changes, be considered by the IESG
> for publication as a Standard Track RFC
> (which generally involves an IETF-wide Last Call); or
>
> 2) requiring that outstanding issues be adequately
> addressed prior to further action (including,
> possibly, another WG Last Call).
>
> Remember that it is our responsibility as Working Group members to
> ensure the quality of our documents and of the Internet Standards
> process. So, please read and comment!
>
> Blake
> --
> Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
>
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 i1N1VDte051982; Sun, 22 Feb 2004 17:31: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 i1N1VDPr051981; Sun, 22 Feb 2004 17:31:13 -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 i1N1VARC051973 for ; Sun, 22 Feb 2004 17:31:11 -0800 (PST) (envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Sun, 22 Feb 2004 17:31:11 -0800
From: "Blake Ramsdell"
To:
Subject: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
Date: Sun, 22 Feb 2004 17:31:11 -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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This message initiates an SMIME Working Group Last Call on the document:
Title : S/MIME Version 3.1 Certificate Handling
Author(s) : B. Ramsdell
Filename : draft-ietf-smime-rfc2632bis-05.txt
Pages : 13
Date : 2004-2-17
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-05.txt
The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.
Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may
be sent to the document editor.
The Last Call period will end on Monday, March 8, 2004.
Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:
1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as a Standard Track RFC
(which generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process. So, please read and comment!
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
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 i1N1RS6g051835; Sun, 22 Feb 2004 17:27:28 -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 i1N1RSSt051834; Sun, 22 Feb 2004 17:27:28 -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 i1N1RPMq051824 for ; Sun, 22 Feb 2004 17:27:26 -0800 (PST) (envelope-from blake@brutesquadlabs.com)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Sun, 22 Feb 2004 17:27:25 -0800
From: "Blake Ramsdell"
To:
Subject: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
Date: Sun, 22 Feb 2004 17:27:25 -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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This message initiates an SMIME Working Group Last Call on the document:
Title : S/MIME Version 3.1 Message Specification
Author(s) : B. Ramsdell
Filename : draft-ietf-smime-rfc2633bis-07.txt
Pages : 31
Date : 2004-2-17
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-07.txt
The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.
Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may
be sent to the document editor.
The Last Call period will end on Monday, March 8, 2004.
Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:
1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as a Standard Track RFC
(which generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process. So, please read and comment!
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C4lRgH020023; Wed, 11 Feb 2004 20:47:27 -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 i1C4lRvG020022; Wed, 11 Feb 2004 20:47:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from fledermaus.treasury.govt.nz ([202.36.173.38]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C4jPgg019893 for ; Wed, 11 Feb 2004 20:46:11 -0800 (PST) (envelope-from Craig.McGregor@treasury.govt.nz)
Received: from juliet.hamlet.treasury.govt.nz (Not Verified[172.20.2.43]) by fledermaus.treasury.govt.nz with Non-Descript e-mail server id ; Thu, 12 Feb 2004 17:40:43 +1300
MIME-Version: 1.0
Subject: Using S/MIME for Domain to Domain Security - experience from a real world deployment
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Thu, 12 Feb 2004 17:42:12 +1300
Message-ID: <14270A31340CCF46A050FEC25B8F50A00693F0A4@juliet.hamlet.treasury.govt.nz>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Using S/MIME for Domain to Domain Security - experience from a real world deployment
Thread-Index: AcPgMxR4QhthgT4WSqqt39NlzBet/QP6s7JQ
From: "Craig McGregor"
To:
Cc: "Russ Housley" , "Ben Littauer"
content-class: urn:content-classes:message
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1C4kBgg019926
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Part 1: The Test Lab (October 2000)
===================================
After receiving responses from an RFP, three vendors claimed that they
could supply a solution using S/MIME gateway products. We created a
test-lab (October 2000) to test the interoperability between these three
S/MIME gateway products. Typically these products were e-mail content
filters with S/MIME add-ons - although content filtering was not part of
our requirements.
Achieving interoperability was a more challenging task than we first
envisaged.
We relatively quickly got to a stage where we were able to achieve one
way interoperability between products - We had a scenario similar to:
Product A could send to Product B but not to Product C
Product A could receive from Product C but not from Product B
Product B could send to Product C but not to Product A
Product B could receive from Product A but not from Product C
Product C could send to Product A but not to Product B
Product C could receive from Product B but not from Product A
Obviously the fact that although each product used S/MIME there had not
been much interoperability testing with other products.
It was clear that each product was implemented very differently for how
they identified domain secured e-mail. One product implemented a very
early draft of what is now RFC3183, another relied on a custom X-Header
line and the other implemented manually configured matching.
There were also some issues even with the S/MIME implementations
interoperating as well. E.g. When certain elements of s/mime messages
were DER encoded rather than BER encoded would cause one product to fail
- but not the others...
We were eventually able to get each product interoperating after some
testing of why products didn't like each other and a combination of
vendor provided work-arounds, patches and upgrades to their software.
- All three products were able to deal with manually configured groups
of domains for gateway to gateway S/MIME interoperation
- Interoperability was only achievable by using a lowest common
denominator approach of S/MIME v2. We also applied the naming
conventions from the DOMSEC draft of the time to ensure that we had
consistent naming conventions in our certificates.
- There was not a great deal of vendor enthusiasm for updating their
products to enable us to upgrade our interoperability spec to use either
draft or experimental technical specifications because of the potential
for such specifications to be 'moving goalposts'. There were suggestions
that the relevant product managers would consider support for something
that was deemed 'standard' in their products.
To state the obvious it would have been ideal if all S/MIME gateway
products were able to interoperate 'out-of-the-box' and thereby reduce
our necessary testing to compliance with our business rules rather than
with technical specifications and our business rules.
Part 2: A pilot group and a small community of participating domains
(Nov 2000 - Early 2001)
========================================================================
=====================
We started with a pilot between three central government agencies - The
Treasury, The State Services Commission and Parliament.
This pilot involved a manual exchange of certificates between the
gateways and was highly successful. End users no longer needed to manage
certificates, or, choose whether to secure a message - it just happened
for them.
We had now secured internet e-mail communications between more users
than was possible during our previous (failed) pilot of
desktop-to-desktop e-mail security.
Other government agencies joined our secure e-mail community. It had now
become the standard way of securing e-mail between public-sector
agencies.
As more and more agencies joined the use of manual certificate exchanges
were becoming burdensome in the opinion of system administrators at some
government agencies.
We found that manually implemented key management was prone to errors
because system administrators key management operations were not
performed regularly - once a year for your own domain and a few times a
year for the different expiry dates on the other domains. Similarly,
keys seemed to expire at inconvenient times (such as when system
administrator was away) and cause e-mail disruptions. There is a
potential paradox between e-mail being high availability and PKI being
"failsafe" for high security (therefore stopping if something is wrong).
Part 3: Managing a large community of participating domains (2002-2004)
=======================================================================
A. SMARTS (S.E.E. Mail Automated Reference Test Server)
Misconfiguration of S/MIME gateways in participating domains can cause
delivery of e-mail to other participating domains if such
misconfiguration does not conform to the business rules, and thus an
e-mail alert would be sent to the end user. E.g. a Postmaster
Non-Delivery notification is not signed and encrypted by a participating
domain, then the recipient of another participating domain will get an
e-mail to say the e-mail (the NDR) was received insecurely.
To counter problems created from configuration errors of S/MIME gateways
we setup a test server that works by exchanging e-mail with an
administrator from a participating domain. This test suite of e-mails
contains tests for our business rules and any exceptions that we have
found to cause problems over time. An administrator from a participating
domain is therefore able to test that they correctly process e-mail as
per the business rules whenever they make configuration changes to their
networks.
The SMARTS server tests for compliance with our business rules rather
than interoperability which is proven before upgrades or new products
are included in our S.E.E. Mail community.
B. Key Management
As the size of a 'community' that secures their e-mail communications
grows, the likelihood of poor key management occurring and having a
negative impact on the system increases. Using server-side software,
rather than interactive client software means that choices cannot be
made interactively at the time if there is a problem with a certificate
(e.g. expired, revoked). Some automation is required in order to take
some action - you cannot put a prompt on the screen and expect a user to
do something about it!
To correct this we have required changes to the products used in S.E.E.
Mail to be able to use an LDAP directory for two purposes:
- To obtain the current membership list of the S.E.E. Mail
community. (i.e. which domains need S/MIME gateway
signing/encryption/decryption applied)
- To obtain the current certificates for members of the S.E.E.
Mail community (e.g. a certificate becomes invalid, new member)
Where to from here?
===================
When comparing our real world deployment against the specifications
contained in RFC3183 there would appear to be a number potential areas
for simplification of RFC3183, or, possibly an opportunity for a
completely new rewrite that is a simpler Informational or Standards
track RFC along the lines "Securing e-mail between domains using
S/MIMEv3.1".
For more information on the S.E.E. Mail project please refer to
http://e.govt.nz/see/mail/
You may also be interested in a similar project by the Massachusetts
Health Data Consortium http://www.mahealthdata.org/initiatives/e-mail/.
Although I have not had any involvement in this project, the
documentation contained on their website shows very similar findings to
the S.E.E. Mail project.
-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Thursday, 22 January 2004 4:26 a.m.
To: Craig McGregor; ietf-smime@imc.org
Subject: Re: Status of RFC3183: Domain Security Services using S/MIME
If there is sufficient experience from deployments such as yours, then I
would not be opposed to expending the charter of the S/MIME WG to
progress
the DOMSEC document from Experimental to the Standards Track. Of
course,
people with the lessons learned from such deployments must be willing to
participate in the discussions.
Russ
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14Hwn1M068752; Wed, 4 Feb 2004 09:58:49 -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 i14Hwnou068751; Wed, 4 Feb 2004 09:58:49 -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 i14HwjeN068728 for ; Wed, 4 Feb 2004 09:58:47 -0800 (PST) (envelope-from turners@ieca.com)
Received: from unknown (HELO ieca.com) (turners@ieca.com@141.156.178.221 with plain) by smtp006.bizmail.sc5.yahoo.com with SMTP; 4 Feb 2004 17:58:51 -0000
Message-ID: <4021310D.8090602@ieca.com>
Date: Wed, 04 Feb 2004 12:51:09 -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: SMIME
Subject: 59th IETF Agenda Topics
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:
All,
Here's a suggested Agenda. Anyone have anything they'd like to add?
Introductions (Sean Turner)
Working group status (Sean Turner)
CMS and ESS examples update (Paul Hoffman)
MSGbis and CERTbis update (Sean Turner)
KEM status (?)
GOST status (?)
SEED Update (Jongwook Park)
spt