Subject: ***SPAM*** 90.988 (5) Do you want enlargye your penips? loccyb

From: "Sammy Hodge" <[email-masked]>
Date: Fri, 01 Feb 2008 06:52:47 +0000

Dear [email-masked]

http://iuyregaea.com

A breakthrough in herbal Science has created a pill that has been designed specifically for penis enlargement.
 The tests that took place over a 6 month period showed that out of the 5,000 
Males from around the world who participated, the average gain after 5 months of taking ManSter 
pills was 3.02 Inches! 

Amazing, PERMANENT RESULTS that will last.

ť Gain 3+ Inches In Length.
ť Increase Your Penis Width (Girth) By upto 20%.
ť Help Stop Premature Ejaculation!
ť Produce Stronger, Rock Hard Erections.
ť 100% Safe To Take, With NO Side Effects.
ť Fast Shipping WorldWide.
ť Doctor Approved And Recommended.
ť No Pumps! No Surgery! No Exercises!
ť Very discrete shipping and billing
ť 100% Money Back Guarantee.
ť *3 FREE Bottles Of ManSter !!
ť Highly secure 128bit order processing 

http://iuyregaea.com

Thanks
Cathy Moore

[email-masked] wrote:
> Add up to 4 inches to yours penis
piy61o15sm-
out me now
http://iuyregaea.com/w.php

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-ietf-smime-sha2-03.txt 
Date: Wed, 30 Jan 2008 11:44:26 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This draft incorporates some suggested changes I received offlist. All but
one was editorial, which was to point to FIPS 180-3 vice -2. Since we point
to FIPS 186-3 instead of -2 it seemed like a good idea to point to the most
up to date doc.

spt

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Wednesday, January 30, 2008 11:40 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: I-D Action:draft-ietf-smime-sha2-03.txt 
>
>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           : Using SHA2 Algorithms with 
>Cryptographic Message Syntax
>	Author(s)       : S. Turner
>	Filename        : draft-ietf-smime-sha2-03.txt
>	Pages           : 10
>	Date            : 2008-01-30
>
>This document describes the conventions for using the message 
>digest algorithms SHA-224, SHA-256, SHA-384, SHA-512, as 
>defined in FIPS 180-3, with the Cryptographic Message Syntax 
>(CMS). It also describes the conventions for using these 
>algorithms with CMS and the DSA, RSA, and ECDSA signature algorithms. 
>
>
> 
> 
> Conventions used in this document 
>
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
>NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
>"OPTIONAL" in this document are to be interpreted as described 
>in [RFC2119].
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt
>
>To remove yourself from the I-D Announcement list, send a 
>message to [email-masked] with the word 
>unsubscribe in the body of the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>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-sha2-03.txt".
>
>A list of Internet-Drafts directories can be found in 
>http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-sha2-03.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.
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-smime-sha2-03.txt 
Date: Wed, 30 Jan 2008 11:40:02 -0500
Sender: [email-masked]

--NextPart

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

	Title           : Using SHA2 Algorithms with Cryptographic Message Syntax
	Author(s)       : S. Turner
	Filename        : draft-ietf-smime-sha2-03.txt
	Pages           : 10
	Date            : 2008-01-30

This document describes the conventions for using the message digest 
algorithms SHA-224, SHA-256, SHA-384, SHA-512, as defined in FIPS 
180-3, with the Cryptographic Message Syntax (CMS). It also describes 
the conventions for using these algorithms with CMS and the DSA, RSA, 
and ECDSA signature algorithms. 

 
 Conventions used in this document 

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

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-sha2-03.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-sha2-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-sha2-03.txt

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

Content-Type: text/plain
Content-ID:     <2008-01-30113255.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-smime-symkeydist-10.txt 
Date: Mon, 28 Jan 2008 16:20:02 -0500
Sender: [email-masked]

--NextPart

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

	Title           : CMS Symmetric Key Management and Distribution
	Author(s)       : S. Turner
	Filename        : draft-ietf-smime-symkeydist-10.txt
	Pages           : 89
	Date            : 2008-01-28

This document describes a mechanism to manage (i.e., setup, 
distribute, and rekey) keys used with symmetric cryptographic 
algorithms. Also defined herein is a mechanism to organize users into 
groups to support distribution of encrypted content using symmetric 
cryptographic algorithms. The mechanism uses the Cryptographic 
Message Syntax (CMS) protocol [CMS] and Certificate Management 
Message over CMS (CMC) protocol [CMC] to manage the symmetric keys. 
Any member of the group can then later use this distributed shared 
key to decrypt other CMS encrypted objects with the symmetric key. 
 
 This mechanism has been developed to support S/MIME Mail List Agents 
(MLAs). 

Conventions used in this document 

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

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-symkeydist-10.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-symkeydist-10.txt

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

Content-Type: text/plain
Content-ID:     <2008-01-28161603.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-smime-sha2-02.txt 
Date: Mon, 28 Jan 2008 10:20:02 -0500
Sender: [email-masked]

--NextPart

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

	Title           : Using SHA2 Algorithms with Cryptographic Message Syntax
	Author(s)       : S. Turner
	Filename        : draft-ietf-smime-sha2-02.txt
	Pages           : 10
	Date            : 2008-01-28

This document describes the conventions for using the message digest 
algorithms SHA-224, as defined in [RFC3874], and SHA-256, SHA-384, 
SHA-512, as defined in [SHA2], with the Cryptographic Message Syntax 
(CMS) [RFC3852]. It also describes the conventions for using these 
algorithms with CMS and the DSA, RSA, and ECDSA signature algorithms. 

 
 Conventions used in this document 

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

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-sha2-02.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-sha2-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

Content-Type: text/plain
Content-ID:     <2008-01-28101319.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Date: Fri, 25 Jan 2008 17:13:02 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Fwd: RFC 5114 on Additional Diffie-Hellman Groups for Use with IETF 	Standards
Sender: [email-masked]

>A new Request for Comments is now available in online RFC libraries.
>
>        
>         RFC 5114
>
>         Title:      Additional Diffie-Hellman Groups for Use
>                     with IETF Standards
>         Author:     M. Lepinski, S. Kent
>         Status:     Informational
>         Date:       January 2008
>         Mailbox:    [email-masked],
>                     [email-masked]
>         Pages:      23
>         Characters: 49565
>         Updates/Obsoletes/SeeAlso:   None
>
>         I-D Tag:    draft-lepinski-dh-groups-03.txt
>
>         URL:        http://www.rfc-editor.org/rfc/rfc5114.txt
>
>This document describes eight Diffie-Hellman groups that can be used
>in conjunction with IETF protocols to provide security for Internet
>communications.  The groups allow implementers to use the same groups
>with a variety of security protocols, e.g., SMIME, Secure SHell (SSH),
>Transport Layer Security (TLS), and Internet Key Exchange (IKE).
>
>All of these groups comply in form and structure with relevant
>standards from ISO, ANSI, NIST, and the IEEE.  These groups are
>compatible with all IETF standards that make use of Diffie-Hellman or
>Elliptic Curve Diffie-Hellman cryptography.
>
>These groups and the associated test data are defined by NIST on
>their web site [EX80056A], but have not yet (as of this writing) been
>published in a formal NIST document.  Publication of these groups and
>associated test data, as well as describing how to use Diffie-Hellman
>and Elliptic Curve Diffie-Hellman for key agreement in all of the
>protocols cited below, in one RFC, will facilitate development of
>interoperable implementations and support the Federal Information
>Processing Standard (FIPS) validation of
>implementations that make use of these groups.  This memo provides
>information for the Internet community.
>
>
>INFORMATIONAL: This memo provides information for the Internet community.
>It does not specify an Internet standard of any kind. Distribution
>of this memo is unlimited.

S/MIME implementers should see especially section 3.1 and 3.5.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 24 Jan 2008 18:02:17 -0500
To: Simon Josefsson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Sender: [email-masked]

Simon:

>Thanks!  I prefer *.p7s for CMS.
>
>I looked over the rest of the document, and it seems fine.
>
>It would be useful to add to the security considerations that the
>Secretariat SHOULD/MUST be careful to have correct time on their
>machines.  Otherwise the Signing-Time attribute is not particularly
>useful, as RFC 3852 doesn't require correctness of the value in that
>attribute.

Good suggestion.  Will do.

>Was allowing end-to-end signatures considered?  That would allow people
>to be certain that the draft they retrieve from the IETF actually is the
>same that was submitted to the IETF.

Yes, I thought about it, but I do not want to require authors to have 
certificates.

Russ

From: Simon Josefsson <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: Blake Ramsdell <[email-masked]>, [email-masked]
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 24 Jan 2008 22:05:20 +0100
Sender: [email-masked]

Thanks!  I prefer *.p7s for CMS.

I looked over the rest of the document, and it seems fine.

It would be useful to add to the security considerations that the
Secretariat SHOULD/MUST be careful to have correct time on their
machines.  Otherwise the Signing-Time attribute is not particularly
useful, as RFC 3852 doesn't require correctness of the value in that
attribute.

Was allowing end-to-end signatures considered?  That would allow people
to be certain that the draft they retrieve from the IETF actually is the
same that was submitted to the IETF.

/Simon

Russ Housley <[email-masked]> writes:

> I just submitted -01, which changes ".sig" to ".p7s"
>
> Russ
>
>
> At 09:31 AM 1/24/2008, Russ Housley wrote:
>
>>Blake:
>>
>>Sorry.  I was clearly too terse.
>>
>>Perhaps I'm missing something, but this line:
>> >
>> >    application/pkcs7-signature (SignedData)                .p7s
>> >
>> lead me to believe that the .p7s was used along with the
>> application/pkcs7-signature MIME type.  Since there was no MIME
>> encoding involve, I though this was the wrong selection.
>>
>>I'm pleased to use .p7s if my interpretation was incorrect.
>>
>>Russ
>>
>>
>>At 07:23 PM 1/23/2008, Blake Ramsdell wrote:
>>
>>>On Wed, Jan 23, 2008 at 03:34:46PM -0500, Russ Housley wrote:
>>> >  Maybe I'm reading it wrong.  Where is the MIME type in my specification?
>>>
>>>* In your draft, you say:
>>>
>>>The companion signature file has exactly the same file name as the
>>>Internet-Draft, except that ".sig" is added to the end.
>>>
>>>* If I understand it right, the content of this ".sig" file is a CMS
>>>   SignedData object with no content (a detached signature)
>>>
>>>* In the S/MIME Message specification, the file extension that is used for a
>>>   CMS SignedData object with no content (a detached signature) is .p7s
>>>
>>>* My observation, based on Simon's observation, is that the .p7s file
>>>   extension might be more in line with current practice
>>>
>>>Now, I'm not sure that the universe would end if this convention wasn't
>>>followed.
>>>
>>>Blake
>>>--
>>>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
>>

Date: Thu, 24 Jan 2008 13:51:42 -0500
To: Blake Ramsdell <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Sender: [email-masked]

I just submitted -01, which changes ".sig" to ".p7s"

Russ

At 09:31 AM 1/24/2008, Russ Housley wrote:

>Blake:
>
>Sorry.  I was clearly too terse.
>
>Perhaps I'm missing something, but this line:
> >
> >    application/pkcs7-signature (SignedData)                .p7s
> >
>lead me to believe that the .p7s was used along with the 
>application/pkcs7-signature MIME type.  Since there was no MIME 
>encoding involve, I though this was the wrong selection.
>
>I'm pleased to use .p7s if my interpretation was incorrect.
>
>Russ
>
>
>At 07:23 PM 1/23/2008, Blake Ramsdell wrote:
>
>>On Wed, Jan 23, 2008 at 03:34:46PM -0500, Russ Housley wrote:
>> >  Maybe I'm reading it wrong.  Where is the MIME type in my specification?
>>
>>* In your draft, you say:
>>
>>The companion signature file has exactly the same file name as the
>>Internet-Draft, except that ".sig" is added to the end.
>>
>>* If I understand it right, the content of this ".sig" file is a CMS
>>   SignedData object with no content (a detached signature)
>>
>>* In the S/MIME Message specification, the file extension that is used for a
>>   CMS SignedData object with no content (a detached signature) is .p7s
>>
>>* My observation, based on Simon's observation, is that the .p7s file
>>   extension might be more in line with current practice
>>
>>Now, I'm not sure that the universe would end if this convention wasn't
>>followed.
>>
>>Blake
>>--
>>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
>

Date: Thu, 24 Jan 2008 09:31:39 -0500
To: Blake Ramsdell <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Sender: [email-masked]

Blake:

Sorry.  I was clearly too terse.

Perhaps I'm missing something, but this line:
 >
 >    application/pkcs7-signature (SignedData)                .p7s
 >
lead me to believe that the .p7s was used along with the 
application/pkcs7-signature MIME type.  Since there was no MIME 
encoding involve, I though this was the wrong selection.

I'm pleased to use .p7s if my interpretation was incorrect.

Russ

At 07:23 PM 1/23/2008, Blake Ramsdell wrote:

>On Wed, Jan 23, 2008 at 03:34:46PM -0500, Russ Housley wrote:
> >  Maybe I'm reading it wrong.  Where is the MIME type in my specification?
>
>* In your draft, you say:
>
>The companion signature file has exactly the same file name as the
>Internet-Draft, except that ".sig" is added to the end.
>
>* If I understand it right, the content of this ".sig" file is a CMS
>   SignedData object with no content (a detached signature)
>
>* In the S/MIME Message specification, the file extension that is used for a
>   CMS SignedData object with no content (a detached signature) is .p7s
>
>* My observation, based on Simon's observation, is that the .p7s file
>   extension might be more in line with current practice
>
>Now, I'm not sure that the universe would end if this convention wasn't
>followed.
>
>Blake
>--
>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

From: Simon Josefsson <[email-masked]>
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 24 Jan 2008 08:54:24 +0100
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:

> Russ Housley <[email-masked]> writes:
>
>>You raise an important consideration.  I do not know the answer.  Do others?
>
> The de facto standard for classic PGP is .asc (for ASCII-armoured detached
> sigs).  GPG used to use .sig, but I don't know if it still does.

GnuPG uses *.sig for detached binary signatures, and *.asc for ASCII
armored.  GnuPG still does this, all releases of my projects are signed
with a *.sig file.  I wouldn't be surprised if this was inherited from
original PGP, but I don't know for sure.

> What's wrong with using the traditional .p7s?

I would prefer that as well, unless there are good reasons not to.

/Simon

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Date: Thu, 24 Jan 2008 17:00:23 +1300
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>You raise an important consideration.  I do not know the answer.  Do others?

The de facto standard for classic PGP is .asc (for ASCII-armoured detached
sigs).  GPG used to use .sig, but I don't know if it still does.

What's wrong with using the traditional .p7s?

Peter.

Date: Wed, 23 Jan 2008 16:23:11 -0800
From: Blake Ramsdell <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Sender: [email-masked]

On Wed, Jan 23, 2008 at 03:34:46PM -0500, Russ Housley wrote:
>  Maybe I'm reading it wrong.  Where is the MIME type in my specification?

* In your draft, you say:

The companion signature file has exactly the same file name as the
Internet-Draft, except that ".sig" is added to the end.

* If I understand it right, the content of this ".sig" file is a CMS
  SignedData object with no content (a detached signature)

* In the S/MIME Message specification, the file extension that is used for a
  CMS SignedData object with no content (a detached signature) is .p7s

* My observation, based on Simon's observation, is that the .p7s file
  extension might be more in line with current practice

Now, I'm not sure that the universe would end if this convention wasn't
followed.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Date: Wed, 23 Jan 2008 15:34:46 -0500
To: Blake Ramsdell <[email-masked]>, Simon Josefsson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Sender: [email-masked]

Blake:

Maybe I'm reading it wrong.  Where is the MIME type in my specification?

Russ

At 03:19 PM 1/23/2008, Blake Ramsdell wrote:
>On Wed, Jan 23, 2008 at 06:40:24PM +0100, Simon Josefsson wrote:
> > While strictly not CMS related (is there a more appropriate mailing list
> > to discuss the draft?), I wonder whether using *.sig as the extension
> > for detached CMS signatures is standardized?
>
>RFC 3851 (the S/MIME message spec) indicates the use of ".p7s" for detached
>signatures in section 3.2.1:
>
>] 3.2.1. The name and filename Parameters
>]
>]    For the application/pkcs7-mime, sending agents SHOULD emit the
>]    optional "name" parameter to the Content-Type field for compatibility
>]    with older systems.  Sending agents SHOULD also emit the optional
>]    Content-Disposition field [CONTDISP] with the "filename" parameter.
>]    If a sending agent emits the above parameters, the value of the
>]    parameters SHOULD be a file name with the appropriate extension:
>] ...
>] application/pkcs7-signature (SignedData)                .p7s
>
>In the old days I made a .p7s handler for Windows so if you double-clicked on
>a .p7s file, it would look for another file with the same base filename and
>validate the signature on it. Not sure if this practice is common with
>contemporary agents.
>
>Blake
>--
>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Date: Wed, 23 Jan 2008 12:19:48 -0800
From: Blake Ramsdell <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked]
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Sender: [email-masked]

On Wed, Jan 23, 2008 at 06:40:24PM +0100, Simon Josefsson wrote:
> While strictly not CMS related (is there a more appropriate mailing list
> to discuss the draft?), I wonder whether using *.sig as the extension
> for detached CMS signatures is standardized?

RFC 3851 (the S/MIME message spec) indicates the use of ".p7s" for detached
signatures in section 3.2.1:

] 3.2.1. The name and filename Parameters
] 
]    For the application/pkcs7-mime, sending agents SHOULD emit the
]    optional "name" parameter to the Content-Type field for compatibility
]    with older systems.  Sending agents SHOULD also emit the optional
]    Content-Disposition field [CONTDISP] with the "filename" parameter.
]    If a sending agent emits the above parameters, the value of the
]    parameters SHOULD be a file name with the appropriate extension:
] ...
] application/pkcs7-signature (SignedData)                .p7s

In the old days I made a .p7s handler for Windows so if you double-clicked on
a .p7s file, it would look for another file with the same base filename and
validate the signature on it. Not sure if this practice is common with
contemporary agents.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Date: Wed, 23 Jan 2008 11:06:00 -0800
To: Simon Josefsson <[email-masked]>, Russ Housley <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 6:40 PM +0100 1/23/08, Simon Josefsson wrote:
>While strictly not CMS related (is there a more appropriate mailing list
>to discuss the draft?), I wonder whether using *.sig as the extension
>for detached CMS signatures is standardized?  That file extension is
>frequently used for OpenPGP signatures in practice.

It is not standardized for either (I believe), and it is already 
common for both.

Date: Wed, 23 Jan 2008 13:56:32 -0500
To: Simon Josefsson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
Cc: [email-masked]
Sender: [email-masked]

Simon:

You raise an important consideration.  I do not know the answer.  Do others?

Russ

At 12:40 PM 1/23/2008, Simon Josefsson wrote:
>While strictly not CMS related (is there a more appropriate mailing list
>to discuss the draft?), I wonder whether using *.sig as the extension
>for detached CMS signatures is standardized?  That file extension is
>frequently used for OpenPGP signatures in practice.
>
>It may be nice to consider using another file extension, to avoid format
>confusion.  I realize that if use of *.sig is already wide-spread for
>detached CMS signatures, the document might as well follow that
>precedent.  Further, I don't know whether the practice of using *.sig
>for OpenPGP signatures is standardized.
>
>/Simon
>
>Russ Housley <[email-masked]> writes:
>
> > This document makes use of CMS, so I'd appreciate review from this group.
> >
> > Russ
> >
> >
> >> draft-housley-internet-draft-sig-file-00.txt has been submitted to
> >> the IETF repository.
> >>
> >>Filename:       draft-housley-internet-draft-sig-file
> >>Revision:       00
> >>Title:          Digital Signatures on Internet-Draft Documents
> >>Creation_date:  2008-01-23
> >>WG ID:          Independent Submission
> >>Number_of_pages: 12
> >>
> >>Abstract:
> >>This document specifies the conventions for digital signatures on
> >>Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to
> >>create a detached signature, which is stored in a separate companion
> >>file so that no existing utilities are impacted by the addition of
> >>the digital signature.

From: Simon Josefsson <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: Please review draft-housley-internet-draft-sig-file-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 23 Jan 2008 18:40:24 +0100
Sender: [email-masked]

While strictly not CMS related (is there a more appropriate mailing list
to discuss the draft?), I wonder whether using *.sig as the extension
for detached CMS signatures is standardized?  That file extension is
frequently used for OpenPGP signatures in practice.

It may be nice to consider using another file extension, to avoid format
confusion.  I realize that if use of *.sig is already wide-spread for
detached CMS signatures, the document might as well follow that
precedent.  Further, I don't know whether the practice of using *.sig
for OpenPGP signatures is standardized.

/Simon

Russ Housley <[email-masked]> writes:

> This document makes use of CMS, so I'd appreciate review from this group.
>
> Russ
>
>
>> draft-housley-internet-draft-sig-file-00.txt has been submitted to
>> the IETF repository.
>>
>>Filename:       draft-housley-internet-draft-sig-file
>>Revision:       00
>>Title:          Digital Signatures on Internet-Draft Documents
>>Creation_date:  2008-01-23
>>WG ID:          Independent Submission
>>Number_of_pages: 12
>>
>>Abstract:
>>This document specifies the conventions for digital signatures on
>>Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to
>>create a detached signature, which is stored in a separate companion
>>file so that no existing utilities are impacted by the addition of
>>the digital signature.

Date: Wed, 23 Jan 2008 10:05:10 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Please review draft-housley-internet-draft-sig-file-00.txt
Sender: [email-masked]

This document makes use of CMS, so I'd appreciate review from this group.

Russ

>draft-housley-internet-draft-sig-file-00.txt has been submitted to 
>the IETF repository.
>
>Filename:       draft-housley-internet-draft-sig-file
>Revision:       00
>Title:          Digital Signatures on Internet-Draft Documents
>Creation_date:  2008-01-23
>WG ID:          Independent Submission
>Number_of_pages: 12
>
>Abstract:
>This document specifies the conventions for digital signatures on
>Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to
>create a detached signature, which is stored in a separate companion
>file so that no existing utilities are impacted by the addition of
>the digital signature.

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-ietf-smime-multisig-04.txt 
Date: Tue, 22 Jan 2008 14:50:02 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This version incorporates changes to address WG LC comments, ID nits, and
fixing some ASN.1 bugs to make the module compile. We'll forward this
version along to the Security AD.

spt

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Tuesday, January 22, 2008 2:50 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: I-D Action:draft-ietf-smime-multisig-04.txt 
>
>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           : Multiple Signatures in S/MIME
>	Author(s)       : S. Turner, J. Schaad
>	Filename        : draft-ietf-smime-multisig-04.txt
>	Pages           : 20
>	Date            : 2008-01-22
>
>CMS SignedData includes the SignerInfo structure to convey 
>per-signer information. SignedData supports multiple signers 
>and multiple signature algorithms per-signer with multiple 
>SignerInfo structures. 
>If a signer attaches more than one SignerInfo, there are 
>concerns that an attacker could perform a downgrade attack by 
>removing the
>SignerInfo(s) with the 'strong' algorithm(s). This document defines 
> 
> 
> the multiple-signatures attribute, its generation rules, and 
>its processing rules to allow signers to convey multiple 
>SignerInfo while protecting against downgrade attacks. 
>Additionally, this attribute may assist during periods of 
>algorithm migration. 
>
>Conventions used in this document 
>
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
>NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
>"OPTIONAL" in this document are to be interpreted as described 
>in [RFC2119]. 
>
>Discussion 
>
>This draft is being discussed on the 'ietf-smime' mailing 
>list. To subscribe, send a message to 
>[email-masked] with the single word subscribe in 
>the body of the message. There is a Web site for the mailing 
>list at <http://www.imc.org/ietf-smime/>.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-04.txt
>
>To remove yourself from the I-D Announcement list, send a 
>message to [email-masked] with the word 
>unsubscribe in the body of the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>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-multisig-04.txt".
>
>A list of Internet-Drafts directories can be found in 
>http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-multisig-04.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant 
>mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-smime-multisig-04.txt 
Date: Tue, 22 Jan 2008 14:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title           : Multiple Signatures in S/MIME
	Author(s)       : S. Turner, J. Schaad
	Filename        : draft-ietf-smime-multisig-04.txt
	Pages           : 20
	Date            : 2008-01-22

CMS SignedData includes the SignerInfo structure to convey per-signer 
information. SignedData supports multiple signers and multiple 
signature algorithms per-signer with multiple SignerInfo structures. 
If a signer attaches more than one SignerInfo, there are concerns 
that an attacker could perform a downgrade attack by removing the 
SignerInfo(s) with the 'strong' algorithm(s). This document defines 

 the multiple-signatures attribute, its generation rules, and its 
processing rules to allow signers to convey multiple SignerInfo while 
protecting against downgrade attacks. Additionally, this attribute 
may assist during periods of algorithm migration. 

Conventions used in this document 

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

Discussion 

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

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-multisig-04.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-multisig-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-multisig-04.txt

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

Content-Type: text/plain
Content-ID:     <2008-01-22144419.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Cc: [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
To: Peter Gutmann <[email-masked]>
Subject: Re: Public-key distribution via HTTP
Date: Fri, 18 Jan 2008 14:48:21 -0800
Sender: [email-masked]

On Jan 12, 2008, at 12:17 AM, Peter Gutmann wrote:

>
> Don't be mislead by the title (http://www.ietf.org/rfc/rfc4387.txt),  
> it was
> published under the auspices of PKIX but it's really "a simple, fairly
> universal means of publishing your public key via HTTP".  The CACert  
> folks
> have set up a Wiki page to cover implementation info, feedback, and  
> comments:
> http://wiki.cacert.org/wiki/RFC4387.
>

I like it.

The only complaint that I have is that the OpenPGP attributes are a  
bit behind the times. I would like to see it updated for 4880 and  
generalized. I think there are some similar issues for X.509, too.

(Actual technical details -- a key fingerprint there is defined to be  
a binary 160 bits. It ought to be a string because we very well may  
come up with a generic way to compute a fingerprint with an arbitrary  
hash. Given that a fingerprint in this context is really just a  
database retrieval handle (note the way I skillfully avoid the word  
"key"), having it be just text is a good thing. Also, in 4880, we  
deprecate the old-style keys. In the new-style keys, a key ID is just  
a truncation of a fingerprint.)

	Jon

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-smime-sha2-01
Date: Tue, 15 Jan 2008 12:09:22 -0500
Organization: IECA, Inc.
Sender: [email-masked]

The WG LC closed on Wednesday of last week. We received no comments on this
ID. We'll forward it along to the Security AD. 

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Blake Ramsdell
>Sent: Wednesday, December 05, 2007 6:25 PM
>To: [email-masked]
>Subject: WG Last Call: draft-ietf-smime-sha2-01
>
>
>This message initiates an SMIME Working Group Last Call on the 
>document:
>
> Title     : Using SHA2 Algorithms with Cryptographic Message Syntax
> Author(s) : S. Turner
> Filename  : draft-ietf-smime-sha2-01.txt
> Pages     : 10
> Date      : 2007-7-25
>
>This document describes the conventions for using the message 
>digest algorithms SHA-224, as defined in [RFC3874], and 
>SHA-256, SHA-384, SHA-512, as defined in [SHA2], with the 
>Cryptographic Message Syntax (CMS) [RFC3852].
>It also describes the conventions for using these algorithms 
>with CMS and the DSA, RSA, and ECDSA signature algorithms. 
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-01.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 Standards Track RFC.
>
>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 9 Janurary 2008.
>
>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 an Informational 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 | Sendmail, Inc. | http://www.sendmail.com
>

Cc: [email-masked], [email-masked], [email-masked]
From: "Timothy J. Miller" <[email-masked]>
Subject: Re: Public-key distribution via HTTP
Date: Mon, 14 Jan 2008 08:27:50 -0600
To: [email-masked] (Peter Gutmann)
Sender: [email-masked]

--Apple-Mail-1-822858065
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Jan 12, 2008, at 2:17 AM, Peter Gutmann wrote:

> Someone recently asked on a security list whether there was a  
> simple way of
> putting your public key on a web server based on "a set of goals,  
> hopefully
> sufficiently unambitious, so one knows what one wants to do very  
> precisely.
> Given those, I suspect a decent spec replacing hundreds of pages of  
> currently
> 'standard' and useless mechanism could be crafted in about 10 to 30  
> pages)".
> My response was "You've just described RFC 4387 :-)".  The list  
> reaction was
> that no-one had known until then that this document even existed,  
> so I'm
> posting this to a couple of lists where people might find it useful.
>
> Don't be mislead by the title (http://www.ietf.org/rfc/ 
> rfc4387.txt), it was
> published under the auspices of PKIX but it's really "a simple, fairly
> universal means of publishing your public key via HTTP".  The  
> CACert folks
> have set up a Wiki page to cover implementation info, feedback, and  
> comments:
> http://wiki.cacert.org/wiki/RFC4387.
>
> (Please, no religious arguments over this: If you think it's  
> useful, implement
> it.  If not, ignore it).

Peter--

Very timely; we were just discussing something essentially like this  
around my office last week.  I see you've got cryptlib support, but  
are there any other implementations in the pipeline?

-- Tim

--Apple-Mail-1-822858065
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-1-822858065--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Public-key distribution via HTTP
Date: Sat, 12 Jan 2008 21:17:40 +1300
Sender: [email-masked]

[CC'd to various lists who might be interested]

Someone recently asked on a security list whether there was a simple way of
putting your public key on a web server based on "a set of goals, hopefully
sufficiently unambitious, so one knows what one wants to do very precisely.
Given those, I suspect a decent spec replacing hundreds of pages of currently
'standard' and useless mechanism could be crafted in about 10 to 30 pages)".
My response was "You've just described RFC 4387 :-)".  The list reaction was
that no-one had known until then that this document even existed, so I'm
posting this to a couple of lists where people might find it useful.

Don't be mislead by the title (http://www.ietf.org/rfc/rfc4387.txt), it was
published under the auspices of PKIX but it's really "a simple, fairly
universal means of publishing your public key via HTTP".  The CACert folks
have set up a Wiki page to cover implementation info, feedback, and comments:
http://wiki.cacert.org/wiki/RFC4387.

(Please, no religious arguments over this: If you think it's useful, implement
it.  If not, ignore it).

Peter.

Date: Thu, 10 Jan 2008 15:26:09 -0800
To: Stephen Kent <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Seeking comments on draft-ietf-smime-new-asn1-00.txt and   draft-ietf-pkix-new-asn1-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 6:00 PM -0500 1/10/08, Stephen Kent wrote:
>At 2:36 PM -0800 1/10/08, Paul Hoffman wrote:
>>I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?
>>
>>--Paul
>
>you just did send it :-).

Well, now everyone can tell that I got Jim's approval before sending it off...

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 10 Jan 2008 18:00:46 -0500
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Seeking comments on draft-ietf-smime-new-asn1-00.txt and  draft-ietf-pkix-new-asn1-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 2:36 PM -0800 1/10/08, Paul Hoffman wrote:
>I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?
>
>--Paul

you just did send it :-).

Steve

Date: Thu, 10 Jan 2008 14:36:25 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Seeking comments on draft-ietf-smime-new-asn1-00.txt and draft-ietf-pkix-new-asn1-00.txt
Sender: [email-masked]

I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?

--Paul

Greetings again. Jim Schaad and I have produced these two documents 
as WG items, based on the discussion last month in Vancouver. They 
include corrections to our original personal drafts, and some new 
modules. We actively seek comments on these two drafts.

One of the biggest questions is, which RFCs should and should not be 
in the draft? This breaks down into some sub-questions:

- Should we include only standards-track RFCs? What about 
Informational RFCs that came from a WG or were heavily vetted by a WG?

- Should we include RFCs that could benefit from new object classes 
but do not actually need to be updated in order to comply with the 
new ASN.1? Asked another way, should a module that did not contain an 
ANY be included?

- Should we create a module that is just the OIDs assigned across all 
the other modules? Should we create two (one for S/MIME, one for 
PKIX), or just a single OIDs module?

Again, we look forward to the discussion.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 10 Jan 2008 14:59:43 +0000
From: Michael Cheng <[email-masked]>
Subject: RE: I-D Action:draft-gutmann-cms-hmac-enc-00.txt
To: [email-masked], [email-masked]
content-class: urn:content-classes:message
Sender: [email-masked]

Hi Peter,
 
On the definition of Auth-Enveloped for hash-based MAC or other MACs, I have several comments:
 
1. In section 3, change KEK( master_secret ) || HMAC( encrypt( data ) ) to KEK( master_secret ) || encrypt( data )  || MAC( encrypt( data ) ). There is no description to state that HMAC's output includes its input.
 
2. On the generation of CEK-K and HMAC-K, I don't see strong case that the method describe in the draft should be adopted. One call to a KDF to generate both keys from a master key is much simpler and this method is also used in many other standards such ISO 18033-2.
 
3. One may want to use other MAC methods instead of HMAC in considering the security of hash functions.
 
I'd like to suggest the following generic definition following ISO18033-2's DEM definition.
 
Following the CCMP ang GCMP definitions for Auth-Enveloped-Data:
 
ContentEncryptionAlgorithmIdentifier ALGORITHM ::={
 { OID id-aes128-CCM PARAMS CCMParameters } |
 { OID id-aes128-GCM PARAMS GCMParameters } |
 { OID id-data-encapsulation PARMS DEMParams } |
 ... -- Expect additional algorithms --
}
 
DEMParams ::= SEQUENCE {
 keyDerivationFunction KeyDerivationFunction,
 encAlgo      SymmetricCipher,
 macAlgo      MacAlgorithm }
 
KeyDerivationFunction ::= AlgorithmIdentifier {{ KDFAlgorithms }}
KDFAlgorithms ALGORITHM ::= {
 { OID id-PBKDF2 PARAMS PBKDF2-params} | -- For password based authenticated encryption
 { OID id-kdf-kdf1 PARMS HashFunction } | 
 { OID id-kdf-kdf2 PARMS HashFunction } ,  -- For the schemes with the master secret generated by the key transport or key agreement method
 ... -- Expect additional algorithms --
}

SymmetricCipher::= AlgorithmIdentifier {{ SymmetricCiphers }}
SymmetricCiphers ALGORITHM ::= {
 { OID id-aes128-cbc PARMS AES-IV } ,
 ... -- Expect additional algorithms --
}
AES-IV ::= OCTECT STRING

MacAlgorithm ::= AlgorithmIdentifier {{ MACAlgorithms }}
MACAlgorithms ALGORITHM ::= {
 { OID hMAC-SHA1 PARMS NULL } ,
 ... -- Expect additional algorithms such as OMAC or EMAC
}
 
Regards,
 
Michael Cheng

	-----Original Message----- 
	From: [email-masked]  Turner, Sean P. 
	Sent: 2007-12-10 20:50 
	To: [email-masked] 
	Cc: 
	Subject: FW: I-D Action:draft-gutmann-cms-hmac-enc-00.txt

	The following draft was produced by Peter as a result of a thread on the
	S/MIME list from about a year ago. The draft specifies how to use
	Authenticated-Enveloped-Data type with HMAC. Since it has been a year I'd
	like to gauge interest in adopting the draft in the WG. I for one think we
	should address it in S/MIME.
	
	spt
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Monday, December 10, 2007 5:00 AM
	To: [email-masked]
	Subject: I-D Action:draft-gutmann-cms-hmac-enc-00.txt
	
	A New Internet-Draft is available from the on-line Internet-Drafts
	directories.
	
	        Title           : Using HMAC-authenticated Encryption in the
	Cryptographic Message Syntax (CMS)
	        Author(s)       : P. Gutmann
	        Filename        : draft-gutmann-cms-hmac-enc-00.txt
	        Pages           : 13
	        Date            : 2007-12-10
	
	This document specifies the conventions for using HMAC-authenticated
	encryption with the Cryptographic Message Syntax (CMS) authenticated-
	enveloped-data content type.  This mirrors the use of HMAC combined with an
	encryption algorithm that's already employed in IPsec, SSL/ TLS, and SSH,
	which is widely supported in existing crypto libraries and hardware, and has
	been extensively analysed by the crypto community.
	
	A URL for this Internet-Draft is:
	http://www.ietf.org/internet-drafts/draft-gutmann-cms-hmac-enc-00.txt
	
	To remove yourself from the I-D Announcement list, send a message to
	[email-masked] with the word unsubscribe in the body of the
	message.
	You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
	to change your subscription settings.
	
	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-gutmann-cms-hmac-enc-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:
	        [email-masked].
	In the body type:
	        "FILE /internet-drafts/draft-gutmann-cms-hmac-enc-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.

From: "Jim Schaad" <[email-masked]>
To: "'Maxim Masiutin'" <[email-masked]>, <[email-masked]>
Subject: RE: missing algorithm parameters of signatureAlgorithm inside SignerInfo
Date: Thu, 3 Jan 2008 12:35:49 -0800
Sender: [email-masked]

I have a number of questions that need to be answered before I can give you
a correct answer.

1.  What does the appropriate specification state is suppose to be present?
RFC3278 states that the correct SignatureAlgorithm parameters are NULL for
ecdsa-with-SHA1.

2.  Are you looking for the Public Key parameters or the Signature Algorithm
parameters.  Please note that these are different and need to be kept
separately. 

Public key parameter MUST be obtained from the certificate (for certificate
based systems).
Signature algorithm parameters MUST be obtained from the
SignerInfo.signatureAlgorithm

jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Maxim Masiutin
> Sent: Thursday, January 03, 2008 6:28 AM
> To: [email-masked]
> Subject: missing algorithm parameters of signatureAlgorithm inside
> SignerInfo
> 
> 
> I have discussed this issue with Russ Housley and have decided to bring
> it to the public concern. Russ have proposed to deal depending on a
> particular algorithm. I, in contrast, think that this issue is abstract
> and is not related  to any particular algorithm.
> 
> Could you please suggest how to deal with the missing algorithm
> parameters of signatureAlgorithm inside SignerInfo type of SignedData?
> 
> I have found a message signed by an elliptic curve algorithm where
> signature algorithm parameters of signatureAlgorithm inside SignerInfo
> where empty, and the elliptic curve algorithm didn't work without the
> parameters. If I take the parameters from SubjectPublicKeyAlgorithm of
> signer's certificate (sid SignerIdentifier), then the signature
> verification was successful.
> 
> 1.      Is it allowed to take algorithm parameters from signer's
> certificate if they are omitted in signatureAlgorithm of SignerInfo, or
> I should treat such a signature as invalid?
> 2.      If the parameters are both present and different, should I
> treat the signature as invalid or one parameter should overwrite
> another?
> 
> Should we cover this case in a next revision of RFC3369?
> 
> Thank you in advance, and Happy New Year.
> 

Date: Thu, 3 Jan 2008 16:33:10 +0200
From: Maxim Masiutin <[email-masked]>
Organization: Ritlabs
To: [email-masked]
Subject: examples of S/MIME messages with timestamps
Sender: [email-masked]

Could you please send me or publish to the list (or otherwise
published as internet-draft) several examples of S/MIME messages with
timestamps defined in 3126, i.e. signed messages with the Signature
Timestamp attribute (id-aa-signatureTimeStampToken). Thank you in
advance!

Date: Thu, 3 Jan 2008 16:28:01 +0200
From: Maxim Masiutin <[email-masked]>
Organization: Ritlabs
To: [email-masked]
Subject: missing algorithm parameters of signatureAlgorithm inside SignerInfo
Sender: [email-masked]

I have discussed this issue with Russ Housley and have decided to bring it to the public concern. Russ have proposed to deal depending on a particular algorithm. I, in contrast, think that this issue is abstract and is not related  to any particular algorithm.

Could you please suggest how to deal with the missing algorithm parameters of signatureAlgorithm inside SignerInfo type of SignedData?

I have found a message signed by an elliptic curve algorithm where signature algorithm parameters of signatureAlgorithm inside SignerInfo where empty, and the elliptic curve algorithm didnt work without the parameters. If I take the parameters from SubjectPublicKeyAlgorithm of  signers certificate (sid SignerIdentifier), then the signature verification was successful.

1.      Is it allowed to take algorithm parameters from signers certificate if they are omitted in signatureAlgorithm of SignerInfo, or I should treat such a signature as invalid?
2.      If the parameters are both present and different, should I treat the signature as invalid or one parameter should overwrite another?

Should we cover this case in a next revision of RFC3369?

Thank you in advance, and Happy New Year.

Date: Wed, 2 Jan 2008 18:58:27 -0800
To: "Turner, Sean P." <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Comments on S/MIME v3.2
Sender: [email-masked]

At 9:00 AM -0800 12/5/07, Turner, Sean P. wrote:
>At the meeting we had some comments on the S/MIME v3.2 specs 
>(draft-ietf-smime-3850bis-00.txt and 
>draft-ietf-smime-3851bis-00.txt):
>
>  1. Define SHOULD+, SHOULD-, and MUST-.
>  2. Update key size requirements and make sure you differentiate 
>between RSA/DSA and EC key sizes.
>  3. Check that there's no IPR wrt to ECDSA signed certificates and 
>using them with S/MIME.

Certicom has indeed asserted intellectual property rights for ECDSA. 
See <http://www.ietf.org/ietf/IPR/certicom-ipr-rfc-3446.pdf>. The 
last two sentences on the first page are particularly relevant.

As mentioned earlier on this thread, Certicom has also issued an IPR 
statement directly relating to S/MIME: 
<http://www.ietf.org/ietf/IPR/CERTICOM-SMIME>, and has also issued 
another relating directly to ECDSA: 
<http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA>.

Given these, particularly the most recent one pointing out the lack 
of licensing for being able to sign with ECDSA, it seems prudent to 
*not* mention ECDSA anywhere in draft-ietf-smime-3850bis-00.txt and 
draft-ietf-smime-3851bis-00.txt. If someone wants to give any 
specification for ECDSA (such as allocating OIDs or saying how to use 
ECDSA with S/MIME), they can write an individual submission and ask 
for it to become an Informational RFC.

Date: Wed, 02 Jan 2008 10:54:00 -0500
To: [email-masked]
From: Andrew Regenscheid <[email-masked]>
Subject: NIST IBE Workshop
Sender: [email-masked]

NIST is holding a workshop on pairing-based cryptography and 
identity-based encryption in June of 2008.  I believe this is of 
interest to some of you given the S/MIME Working Group's efforts on 
the IBE internet drafts.  This workshop will focus on applications 
and will help us establish direction for future NIST work on 
pairing-based cryptography.  For more information, see the call for 
participation included below.

Thanks,
Andrew Regenscheid, NIST

CALL FOR PARTICIPATION

Applications of Pairing-Based Cryptography: Identity-Based Encryption 
and Beyond
June 3-4, 2008
NIST, Gaithersburg, MD

This workshop brings together academia, government and industry to 
explore innovative and practical applications of pairing-based 
cryptography.  Pairings have been used to create identity-based 
encryption schemes, but are also a useful tool for solving other 
cryptographic problems.  We hope to encourage the development of new 
security applications and communication between researchers, 
developers and users.  In addition to presentations, the workshop 
will facilitate panel discussions among invited experts and workshop 
participants.

CALL FOR PRESENTATIONS
NIST solicits presentations and panel proposals from all interested 
parties, including researchers, system architects, vendors, and 
users. Suggested topics and complete submission details can be found 
at http://www.nist.gov/ibe

IMPORTANT DATES
   --Abstracts due: February 1, 2008
   --Notification to presenters: February 29, 2008
   --Presentation slides due: May 16, 2008

WORKSHOP REGISTRATION FEES
   -- $145 on or before May 10, 2008
   -- $185 after May 10, 2008

More details on the workshop are available at http://www.nist.gov/ibe