Subject: New product! Cialis soft tabs.

From: "Clifford H. Crum" <[email-masked]>
Date: Tue, 30 Nov 2004 15:35:33 -0700

Hi!

We have a new product that we offer to you, C_I_A_L_I_S soft tabs,

Cialis Soft Tabs is the new impotence treatment drug that everyone is talking 
about.Soft Tabs acts up to 36 hours, compare this to only two or three hours
of Viagra action! The active ingredient is Tadalafil, same as in brand Cialis.

Simply disolve half a pill under your tongue, 10 min before sex, for the best 
erections you've ever had!

Soft Tabs also have less sidebacks (you can drive or mix alcohol drinks with them).

You can get it at: http://go-medz.com/soft/

No thanks: http://go-medz.com/rr.php

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2634-update-00.txt
Date: Mon, 29 Nov 2004 15:16:46 -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		: Enhanced Security Services for S/MIME
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-rfc2634-update-00.txt
	Pages		: 31
	Date		: 2004-11-29
	
This document describes the structures and procedures necessary to 
   provide a number of additional security services for S/MIME.  These 
   services are: 
    
   - signed receipts 
   - security labels 
   - secure mailing lists 
   - signing certificate validation 
    
   These services can be used by any CMS (Cryptographic Message Syntax) 
   based protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2634-update-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-ietf-smime-rfc2634-update-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-ietf-smime-rfc2634-update-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2634-update-00.txt

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-00.txt
Date: Fri, 12 Nov 2004 21:43:15 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Tony Capel" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Tony,

Thanks for your review.

Believe it or not but your mail arrived 5 seconds after I hit the send
button to submit an updated draft based on Sean's review :)

So I will hold on the trigger and wait with any changes based on your
comments for inclusion in the next update provided that they are only
editorial.

I comment below;

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Tony Capel [mailto:[email-masked]]
> Sent: den 11 november 2004 21:42
> To: Stefan Santesson; [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-00.txt
> 
> Stefan:
> 
> A nice short document, hopefully the following will be helpful!:
> 
> 
> 1.  Clause 1, Introduction:
> 
> It is understood that the prime driver for this draft is to provide a
> mechanism
> to signal the receiver's available and default encryption algorithms,
but
> it
> might be appropriate to mention in the introduction that the mechanism
> will also
> allow other receiver capabilities to be obtained.  In the first
paragraph
> you
> may wish to add a sentence indicating that capabilities in addition to
the
> encryption algorithms may also be provided.
> 
> In the third paragraph, you may not wish to restrict the mechanism's
> applicability to only encrypted first messages, since it is useful for
> initial
> signed messages as well (e.g. initial signed message may be
compressed).
> Possibly change "encrypted message" to "S/MIME message" to make it
more
> general.

[Stefan] The intention behind this work has primary been to support
encryption in initial messages, but provided that there might be some
use in terms of selecting appropriate signing properties, I have no
problem generalizing the text to "S/MIME message" and using encryption
as a prime example.

If someone thinks this is wrong, then please note me.

> 
> 2.  Clause 3
> 
> In the second paragraph, it is declared out of scope to discuss what
> should be
> considered as a more reliable source of this information.  However, I
> would have
> preferred a note at least introducing the options for establishing the
> precedence of capability information from multiple sources.  For
example:
> 
> The Capabilities in the PKC are inherently signed by the certificate
> issuer, who
> is normally considered more trusted than the end-user who signed the
> Capabilities in a signed message.  (So one approach is to take PKC
> information
> in precedence to Capabilities received in a signed message.)
> 
> Another approach is to presume that the "latest" list should be used.
I
> believe
> this was discussed earlier on the list.
> 
> Another approach when receiving the capabilities from more than one
source
> is to
> use the most restrictive set.
> 

[Stefan] Going into such suggestions is in my mind hard and dangerous.
This draft is limited to the protocol definitions and can't make
authoritative decisions or recommendations regarding the security policy
applied by implementers. Examples you give may be true in some
environments but not in others and this document lack the context to
make any suggestions.

The most we can do is to raise a flag in the security considerations
sections which is already done. I doubt that we can go further than
that.

> 
> 3 Other Issues.
> 
> 3.1  There is no explicit statement that the S/MIME Capabilities are
only
> (?) to
> be included in the encryption PKC in multiple keypair implementations.
I
> assume
> this is intended since it does not make sense to include most
currently
> defined
> S/MIME capability attributes in signing PKC's.  But I worry about the
> compression attribute (for signed-only exchanges where there need be
no
> encryption certificate), and S/MIME Capability attributes are
extensible
> so we
> cannot know the future.  Some explicit guidance may be appropriate
("...
> put the
> attributes in the relevant PKC ..."), and noting that if attributes
are
> duplicated across PKC's they should not conflict.  Right now I think
what
> is put
> in which PKC(s) is open to interpretation (some implementers may put
the
> info in
> all the PKC's).

[Stefan] I object also to this suggestion by the same reason. Every
certificate must be correct on its own merits. A certificate is correct
if it contain the appropriate information for its intended usage. That
is not affected by other certificates hold by the user.

> 
> 3.2  I believe there should be more discussion about the impact of
this
> approach
> on certificate revocation, both in terms of the overhead of re-issuing
> certificates and the impact on the size of the CRL.  In large
> organizations with
> many certificates this may represent a barrier to the use of this
> mechanism.
> 

[Stefan] First I would disagree that this is a likely problem. Our own
experience with using this extension for over 50.000 users has not
driven any increased revocation activity because there is hardly any
event that would cause any such need. The only event we could see is in
the case where a supported algorithm suddenly gets severely broken. In
other cases we find that the encryption policy can be updated in sync
with regular certificate renewals. If an algorithm must be added on
short notice, then we can renew without any need for revocation (the old
list would still be valid, just incomplete).

This issue is however discussed in the security considerations section.
I believe this is sufficient.

> 
> Finally, in Clause 4, "week" should be "weak".
> 

[Stefan] Thanks. This will be changed.

> Regards,
> Tony

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certcapa-01.txt
Date: Fri, 12 Nov 2004 15:07:28 -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		: Certificate extension for S/MIME Capabilities
	Author(s)	: S. Santesson
	Filename	: draft-ietf-smime-certcapa-01.txt
	Pages		: 5
	Date		: 2004-11-12
	
This document defines a certificate extension for inclusion of S/MIME
   capabilities in public key certificates defined by RFC 3280.

   S/MIME Capabilities provides an optional method to communicate
   cryptographic capabilities of the certified subject as a complement
   to use of the S/MIME Capabilities signed attribute in S/MIME messages
   according to RFC 3851.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Tony Capel" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-00.txt
Date: Thu, 11 Nov 2004 15:42:17 -0500
Importance: Normal
Sender: [email-masked]

Stefan:

A nice short document, hopefully the following will be helpful!:

1.  Clause 1, Introduction:

It is understood that the prime driver for this draft is to provide a mechanism
to signal the receiver's available and default encryption algorithms, but it
might be appropriate to mention in the introduction that the mechanism will also
allow other receiver capabilities to be obtained.  In the first paragraph you
may wish to add a sentence indicating that capabilities in addition to the
encryption algorithms may also be provided.

In the third paragraph, you may not wish to restrict the mechanism's
applicability to only encrypted first messages, since it is useful for initial
signed messages as well (e.g. initial signed message may be compressed).
Possibly change "encrypted message" to "S/MIME message" to make it more general.

2.  Clause 3

In the second paragraph, it is declared out of scope to discuss what should be
considered as a more reliable source of this information.  However, I would have
preferred a note at least introducing the options for establishing the
precedence of capability information from multiple sources.  For example:

The Capabilities in the PKC are inherently signed by the certificate issuer, who
is normally considered more trusted than the end-user who signed the
Capabilities in a signed message.  (So one approach is to take PKC information
in precedence to Capabilities received in a signed message.)

Another approach is to presume that the "latest" list should be used.  I believe
this was discussed earlier on the list.

Another approach when receiving the capabilities from more than one source is to
use the most restrictive set.

3 Other Issues.

3.1  There is no explicit statement that the S/MIME Capabilities are only (?) to
be included in the encryption PKC in multiple keypair implementations.  I assume
this is intended since it does not make sense to include most currently defined
S/MIME capability attributes in signing PKC's.  But I worry about the
compression attribute (for signed-only exchanges where there need be no
encryption certificate), and S/MIME Capability attributes are extensible so we
cannot know the future.  Some explicit guidance may be appropriate ("... put the
attributes in the relevant PKC ..."), and noting that if attributes are
duplicated across PKC's they should not conflict.  Right now I think what is put
in which PKC(s) is open to interpretation (some implementers may put the info in
all the PKC's).

3.2  I believe there should be more discussion about the impact of this approach
on certificate revocation, both in terms of the overhead of re-issuing
certificates and the impact on the size of the CRL.  In large organizations with
many certificates this may represent a barrier to the use of this mechanism.

Finally, in Clause 4, "week" should be "weak".

Regards,

Tony

Date: Thu, 11 Nov 2004 15:14:30 -0500
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt
Sender: [email-masked]

I guess I should withdraw #1.  I had this simple idea in mind that we 
had an attribute why not just put it in the repository entry that also 
contains the certificate.  But, we've only got an S/MIME attribute not a 
repository (LDAP/X.500) attribute.

The rest of it looks fine to me.

spt

Stefan Santesson wrote:

>Thanks for the review Sean,
>
>I comment your observations below.
>I have incorporated these changes in a new ID-01 which I will submit as soon as we have agreed on all issues.
>
>Stefan Santesson 
>Microsoft Security Center of Excellence (SCOE) 
>  
>________________________________________
>From: Sean P. Turner [mailto:[email-masked]] 
>Sent: den 8 november 2004 15:46
>To: [email-masked]; Stefan Santesson
>Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt
>
>Stefan,
>
>Here are my comments on the draft:
>1. clause 1, I'd like to see something about why it's better to have it in the PKC than to just rely on the mechanism you used to get the recipient's certificate in the 1st place (you need get the certificate somehow).
>
>[SS] This is the only one I don't understand. What mechanism to obtain the users certificate are u referring to?
>
>If you obtain the certificate from a directory or some other database then there are no specified means of having a signed S/MIME attribute. If you obtain the certificate from a signed mail, then the capabilities in the signed mail should normally have preference, which is stated in section 3.
>
>2. clause 1, I'd like to see something about this being the "static" solution and that dynamic solutions may be defined elsewhere.
>
>[SS] OK, I have added that in the draft update.
>
>3. clause 1, Last para, 1st sentence: r leverage/leverages.
>
>[SS] Fixed in the update.
>
>4. clause 2, 2nd para: r RFC 2633/3851.
>
>[SS] Error corrected in update. I only refer to 3851 though since it obsoletes 2633.
>
>5. clause 2, a "(the following is included for illustrative purposes only)" after following.
>
>[SS] Fixed in update.
>
>6. clause 2, We have to specify whether it's a critical or non-critical extension.
>
>[SS] Fixed. Now says it MUST NOT be critical.
>
>7. clause 2, last para: add period to end of sentence.
>
>[SS] Fixed.
>
>8. clause 4, Are we going to need a module OID for this extension :)  I'm interested to see if using the same attribute/extension OID causes any compilers problems.
>
>[SS] No we don't. I talked to Russ about that. And thus we don't need an ASN.1 section either. I have removed that from the updated ID.
>
>9. clause 5: You need specify which references are normative/informative.
>spt
>
>[SS] Done.
>
>
>[email-masked] wrote:
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the IETF.
>
>	Title		: Certificate extension for S/MIME Capabilities
>	Author(s)	: S. Santesson
>	Filename	: draft-ietf-smime-certcapa-00.txt
>	Pages		: 5
>	Date		: 2004-10-15
>	
>This document defines a certificate extension for inclusion of S/MIME
>   capabilities in public key certificates defined by RFC 3280.
>
>   S/MIME Capabilities provides an optional method to communicate
>   cryptographic capabilities of the certified subject as a complement
>   to use of the S/MIME Capabilities signed attribute in S/MIME messages
>   according to RFC 3851.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-certcapa-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-ietf-smime-certcapa-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-ietf-smime-certcapa-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.
>  
>
>
>  
>

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-00.txt
Date: Thu, 11 Nov 2004 16:57:49 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Sean P. Turner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Thanks for the review Sean,

I comment your observations below.
I have incorporated these changes in a new ID-01 which I will submit as soon as we have agreed on all issues.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: Sean P. Turner [mailto:[email-masked]] 
Sent: den 8 november 2004 15:46
To: [email-masked]; Stefan Santesson
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt

Stefan,

Here are my comments on the draft:
1. clause 1, I'd like to see something about why it's better to have it in the PKC than to just rely on the mechanism you used to get the recipient's certificate in the 1st place (you need get the certificate somehow).

[SS] This is the only one I don't understand. What mechanism to obtain the users certificate are u referring to?

If you obtain the certificate from a directory or some other database then there are no specified means of having a signed S/MIME attribute. If you obtain the certificate from a signed mail, then the capabilities in the signed mail should normally have preference, which is stated in section 3.

2. clause 1, I'd like to see something about this being the "static" solution and that dynamic solutions may be defined elsewhere.

[SS] OK, I have added that in the draft update.

3. clause 1, Last para, 1st sentence: r leverage/leverages.

[SS] Fixed in the update.

4. clause 2, 2nd para: r RFC 2633/3851.

[SS] Error corrected in update. I only refer to 3851 though since it obsoletes 2633.

5. clause 2, a "(the following is included for illustrative purposes only)" after following.

[SS] Fixed in update.

6. clause 2, We have to specify whether it's a critical or non-critical extension.

[SS] Fixed. Now says it MUST NOT be critical.

7. clause 2, last para: add period to end of sentence.

[SS] Fixed.

8. clause 4, Are we going to need a module OID for this extension :)  I'm interested to see if using the same attribute/extension OID causes any compilers problems.

[SS] No we don't. I talked to Russ about that. And thus we don't need an ASN.1 section either. I have removed that from the updated ID.

9. clause 5: You need specify which references are normative/informative.
spt

[SS] Done.

[email-masked] wrote:

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

	Title		: Certificate extension for S/MIME Capabilities
	Author(s)	: S. Santesson
	Filename	: draft-ietf-smime-certcapa-00.txt
	Pages		: 5
	Date		: 2004-10-15
	
This document defines a certificate extension for inclusion of S/MIME
   capabilities in public key certificates defined by RFC 3280.

   S/MIME Capabilities provides an optional method to communicate
   cryptographic capabilities of the certified subject as a complement
   to use of the S/MIME Capabilities signed attribute in S/MIME messages
   according to RFC 3851.

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

Date: Mon, 08 Nov 2004 13:38:47 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: To Meet or Not
Sender: [email-masked]

>Date: Thu, 14 Oct 2004 16:24:43 -0400
>To: [email-masked]
>From: Russ Housley <[email-masked]>
>Subject: RFC 3537 Errata
>
>Dear RFC Editor:
>
>There is a typographical error in section 3.4 of RFC 3537.
>Since this error occurs in an algorithm test vector, it is
>important to publish the corrected data.
>
>OLD:
>
>    PAD          :  38be62
>
>NEW:
>
>    PAD          :  be62fe
>
>Thanks,
>   Russ

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "'Dieter Bratko'" <[email-masked]>, "'SMIME'" <[email-masked]>
Subject: RE: To Meet or Not
Date: Mon, 8 Nov 2004 11:20:18 -0500
Sender: [email-masked]

I concur that there is an error in the document.  My guess is that it was a
cut and paste error as my code produces the correct values, but I tended to
cut the entire blob in and then broke it apart.  Russ and I will get an
errata posted on this issue.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Thursday, October 14, 2004 4:18 PM
> To: Dieter Bratko; SMIME
> Subject: Re: To Meet or Not
> 
> 
> I just reran my test code from the development of this RFC, 
> and you are correct.
> 
> I do not remember if we used my code or Jim's code to 
> generate the test vector data for the RFC, but the PAD value 
> is incorrect in the RFC.
> 
>  >hmac_3des_key_wrap
> 3DES KEK     :
>    KEK Key 1  :  5840df6e 29b02af1
>    KEK Key 2  :  ab493b70 5bf16ea1
>    KEK Key 3  :  ae8338f4 dcc176a8
> 
> Length (L)   :  14
> 
> KEY          :  c37b7e64 92584340
>               :  bed12207 80894115
>               :  5068f738
> 
> PAD          :  be62fe
> 
> ICV          :  1f363a31 cdaa9037
> 
> LKEYPADICV   :  14c37b7e 64925843
>               :  40bed122 07808941
>               :  155068f7 38be62fe
>               :  1f363a31 cdaa9037
> 
> IV           :  050d8c79 e0d56b75
> 
> TEMP1        :  157a8210 f432836b
>               :  a618b096 475c864b
>               :  6612969c dfa445b1
>               :  5646bd00 500b2cc1
> 
> TEMP2        :  050d8c79 e0d56b75
>               :  157a8210 f432836b
>               :  a618b096 475c864b
>               :  6612969c dfa445b1
>               :  5646bd00 500b2cc1
> 
> TEMP3        :  c12c0b50 00bd4656
>               :  b145a4df 9c961266
>               :  4b865c47 96b018a6
>               :  6b8332f4 10827a15
>               :  756bd5e0 798c0d05
> 
> Wrapped Key  :  0f1d715d 75a0aaf6
>               :  6f02e371 c08b79e2
>               :  a1253dc4 3040136b
>               :  dc161118 601f2863
>               :  e2929b3b dd17697c
> 
> 
> At 11:14 AM 10/14/2004, Dieter Bratko wrote:
> 
> >Hello,
> >
> >there seems to be a typo in the HMACwith3DESwrap test vector 
> (chapter 
> >3.4) of RFC 3537. The PAD value is given as 38be62; but should be 
> >be62fe (see LKEYPADICV)?
> >
> >Regards,
> >Dieter Bratko
> >
> >---------
> >Dieter Bratko, mailto:[email-masked] SIC - Stiftung Secure 
> >Information and Communication Technologies IAIK, 
> Inffeldgasse 16a, 8010 
> >Graz, Austria, http://jce.iaik.tugraz.at/
> 
> 
> 

Date: Mon, 08 Nov 2004 09:45:54 -0500
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked], "Santesson, Stefan" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
Here are my comments on the draft:<br>
<ol>
  <li>clause 1, I'd like to see something about why it's better to have
it in the PKC than to just rely on the mechanism you used to get the
recipient's certificate in the 1st place (you need get the certificate
somehow).<br>
  </li>
  <li>clause 1, I'd like to see something about this being the "static"
solution and that dynamic solutions may be defined elsewhere.<br>
  </li>
  <li>clause 1, Last para, 1st sentence: r leverage/leverages.<br>
  </li>
  <li>clause 2, 2nd para: r RFC 2633/3851.</li>
  <li>clause 2, a "(the following is included for illustrative purposes
only)" after following.<br>
  </li>
  <li>clause 2, We have to specify whether it's a critical or
non-critical extension.<br>
  </li>
  <li>clause 2, last para: add period to end of sentence.</li>
  <li>clause 4, Are we going to need a module OID for this extension
:)&nbsp; I'm interested to see if using the same attribute/extension OID
causes any compilers problems.<br>
  </li>
  <li>clause 5: You need specify which references are
normative/informative.</li>
</ol>
spt<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">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		: Certificate extension for S/MIME Capabilities
	Author(s)	: S. Santesson
	Filename	: draft-ietf-smime-certcapa-00.txt
	Pages		: 5
	Date		: 2004-10-15
	
This document defines a certificate extension for inclusion of S/MIME
   capabilities in public key certificates defined by RFC 3280.

   S/MIME Capabilities provides an optional method to communicate
   cryptographic capabilities of the certified subject as a complement
   to use of the S/MIME Capabilities signed attribute in S/MIME messages
   according to RFC 3851.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-smime-certcapa-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-smime-certcapa-00.txt</a>

To remove yourself from the I-D Announcement list, send a message to 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> with the word unsubscribe in the body of the message.  
You can also visit <a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.ietf.org/mailman/listinfo/I-D-announce</a> 
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-certcapa-00.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

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

Send a message to:
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-certcapa-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.
  </pre>
</blockquote>
</body>
</html>