Subject: Document Action: Preventing the Million Message Attack on CMS to Informational

From: The IESG <[email-masked]>
Date: Mon, 29 Oct 2001 16:26:44 -0500

The IESG has approved the Internet-Draft 'Preventing the Million
Message Attack on CMS' <draft-ietf-smime-pkcs1-01.txt> as a
Informational.  This document is the product of the S/MIME Mail
Security Working Group.  The IESG contact persons are Jeffrey Schiller
and Marcus Leech.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Preventing the Million Message Attack on CMS to Informational
Date: Mon, 29 Oct 2001 16:26:44 -0500
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Preventing the Million
Message Attack on CMS' <draft-ietf-smime-pkcs1-01.txt> as a
Informational.  This document is the product of the S/MIME Mail
Security Working Group.  The IESG contact persons are Jeffrey Schiller
and Marcus Leech.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Triple-DES and RC2 Key Wrapping to Informational
Date: Mon, 29 Oct 2001 15:55:55 -0500
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Triple-DES and RC2 Key
Wrapping' <draft-ietf-smime-key-wrap-01.txt> as an Informational RFC.
This document is the product of the S/MIME Mail Security Working
Group.  The IESG contact persons are Jeffrey Schiller and Marcus
Leech.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Password-based Encryption for S/MIME to Proposed Standard
Date: Mon, 29 Oct 2001 12:25:27 -0500
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Password-based Encryption for
S/MIME' <draft-ietf-smime-password-06.txt> as a Proposed Standard.
This document is the product of the S/MIME Mail Security Working
Group.  The IESG contact persons are Jeffrey Schiller and Marcus
Leech.

Technical Summary
 
  This protocol describes a password-based content encryption mechanism
  for CMS.  It is an extension to RFC2630.

Working Group Summary

  There was working group concensus on this protocol.  One minor comment
  was received during last call, which resulted in a minor change to
  the document.

Protocol Quality

  This document was reviewed by Marcus Leech.

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 26 Oct 2001 16:54:14 -0400
Subject: x400transport and x400wrap
Sender: [email-masked]

Jeff & Marcus:

The S/MIME WG is finished with two more documents.  You may recall a 
discussion when this work began, and we concluded that they should be 
published on the Standards Track.  The are ready for your review and IETF 
Last Call.

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-04.txt
	Date		: 19-Oct-01

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-04.txt
	Date		: 27-Aug-01

Russ

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Peter Sylvester <[email-masked]>
Cc: [email-masked]
Subject: RE: sender-auth and ira
Date: Fri, 26 Oct 2001 11:47:35 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C15E4E.ADCE6810
Content-Type: text/plain;
	charset="iso-8859-1"

Oh yeah the BCC to boss strategy...

To: Fred
BCC: Fred's Boss

Fred,
	I completely understand your situation with the possible loss of the
very big important customer account after your unfortunate presentation.
Please let me know if there is anything I can do to help you rectify the
situation.
		Mallet.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 2:21 PM
> To: Peter Sylvester
> Cc: [email-masked]
> Subject: Re: sender-auth and ira
> 
> 
> 
> Peter:
> 
> > > The whole point of BCC recipients is to keep their 
> identities from other
> > > recipients.  If you are going to list them, then they are readily
> > > exposed.  I do not think that we should introduce this leak.
> >
> >Isn't this leak is somewhat similar to the possibility of having
> >one encryption envelope with all addresses in it?
> 
> Yes.  That is why the update to the MSG specification should 
> address BCC in 
> the contect of EnvelopedData.
> 
> Russ
> 

------_=_NextPart_000_01C15E4E.ADCE6810
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:[email-masked]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C15E4E.ADCE6810--

From: "Housley, Russ" <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Date: Fri, 26 Oct 2001 14:20:44 -0400
Subject: Re: sender-auth and ira
Sender: [email-masked]

Peter:

> > The whole point of BCC recipients is to keep their identities from other
> > recipients.  If you are going to list them, then they are readily
> > exposed.  I do not think that we should introduce this leak.
>
>Isn't this leak is somewhat similar to the possibility of having
>one encryption envelope with all addresses in it?

Yes.  That is why the update to the MSG specification should address BCC in 
the contect of EnvelopedData.

Russ

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Oct 2001 17:39:46 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: sender-auth and ira
Cc: [email-masked]
Sender: [email-masked]

> The whole point of BCC recipients is to keep their identities from other 
> recipients.  If you are going to list them, then they are readily 
> exposed.  I do not think that we should introduce this leak.

Isn't this leak is somewhat similar to the possibility of having
one encryption envelope with all addresses in it? 

From: "Housley, Russ" <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Date: Thu, 25 Oct 2001 18:32:30 -0400
Subject: Re: sender-auth and ira
Sender: [email-masked]

Peter:

I will respond to your comment in the ira document.  I will let Don Davis 
respond to the other comments.

>Section 3.0 sentence 2 and 3 should be moved to the end of the section
>where one talks about usage in the context of S/MIME.
>
>Or, a better separation of the definition of this attribut and its
>usage in an S/MIME context should be made.

I am pleased to move it to the end of the section.

>I am not sure whether I support not including BCCs. This should go
>into a security consideration section. The problem is similar of
>what happens in standard bcc: processing. It is up to the sending
>system to create separate messages which may for example include
>one bcc: header for each of the recipients.. similar for S/MIME
>envelopes for BCCs, ...

The whole point of BCC recipients is to keep their identities from other 
recipients.  If you are going to list them, then they are readily 
exposed.  I do not think that we should introduce this leak.

The update to MSG should address BCC in the broader context.

>Anyway, a possible and cost intensive solution is to have separate
>copies with bccs, signed individually, etc. why should one exclude
>this.

Yes, there is a cost.  Again, BCC should be further addressed in the update 
to MSG.

Russ

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: sender-auth and ira
Reply-To: [email-masked]
Date: Fri, 26 Oct 2001 16:58:41 (NZDT)
Sender: [email-masked]

"Jim Schaad" <[email-masked]> writes:
>[Snip]
>
>I think that this is an interesting accademic problem, until I see a real
>world need for a solution I think it should be ignored.

Unaccustomed as I am to agreeing with Jim :-), I concur with this opinion.
Anything of any importance (eg electronic payment instruction, contract, etc)
which relies on signatures will include more than enough information in the
signed body to resolve any difficulties, and even if there were some pressing
demand for this (there isn't), it's not at all clear what a correct solution
would be.

Speaking of academic exercises, I'm surprised noone's mentioned Serge
Vaudenay's PKCS #5 padding attack yet...

Peter.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, <[email-masked]>
Subject: RE: sender-auth and ira
Date: Thu, 25 Oct 2001 19:30:57 -0700
Importance: Normal
Sender: [email-masked]

Russ,

I was hoping that this issue was going to disappear if I ignored it.  I
feel that the problem listed, while potentially interesting, is not one
that can be solved via this type of mechanism.

The problem:  I get a message, signed, and I forward it to you signed
and then possibly encrypted.  You believe that since it was encrypted to
you that nobody else could have sent it but the signer.

Response:  1) A better answer is to put names in e-mail.  2) Am I
suppose to start doing this for all signed mail.  3) How do I convince a
large company like Microsoft that this is even an interesting problem
for them to "fix" in their mail.  4) This does not fix information leaks
in anyway. (A far more interesting problem in my estimation.)

Why this does not work:  I don't know how to begin to tell Microsoft how
to write this code.  The simple case is, if my mail box name is not on
the To/CC line then pop up a warning message.  But this is not an easy
thing to say and program in.  

1. When I was working at Microsoft, people sent me mail at the address
"[email-masked]", my mailbox name was
"[email-masked]".  There is no way to determine that these
are or are not the same address.  While in this case they were they
could just have easily been different addresses.

2. Today, the email address that I give people is "[email-masked]",
but this is not the mail box address that I use.  This address forwards
mail to a second address where I down-load my mail from.  Now either the
message is always going to show up for me, or I have a configuration
issue to explain to users (and to write UI for).

3. If I receive e-mail because I am on a mailing list (such as this
mailing list), either I get the message for all mail to that list, or I
have a configureation issue to explain to users (and to write UI for).
This becomes even more fun if you look at nested mailing lists.  This
mailing list address could be contained on one or more other ietf
mailling lists thus I get mail indirectly and infrequently from some
other entity mailing list that I do not know that I am on.

4. BCC addressing causes massive problems.  Either the message always
comes up, I lose the concept of BCC because the address is included, or
a separate signature operation must be included for every BCC
recipeient.  (Does the BCC signature still have the list of all non-BCC
recipients?).  The process of generating addition signature operations
is not acceptable in my estimation, and would likely generate lots of
interesting problems with signed receipts.

5. What are the correct processing rules to deal with the following
situations:
- Nested signatures:  Does this element in an outer signature remove the
requirement for it to be checked on an inner signature?  Does it add or
change the behavior in some way?
- Parallel signature:  What does this mean for two different
side-by-side signatures, possible with different recipient lists?  If I
am on either list I don't need to display this warning?
- Nested Messages:  What happens if I bodily encapsulate an RFC822
message and forward it to you.  Do you check for the encapsulating but
not the embedded message?  Do you check the embedded message for the
from address of the encapsulating message?

I think that this is an interesting accademic problem, until I see a
real world need for a solution I think it should be ignored.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Thursday, October 25, 2001 7:05 AM
> To: [email-masked]
> Subject: sender-auth and ira
> 
> 
> 
> S/MIME WG:
> 
> Two I-Ds were posted, and I have not seen a single comment on 
> them.  I hope 
> this message starts a dialogue.
> 
> The two I-Ds are:
> 	draft-ietf-smime-sender-auth-00.txt
> 	draft-ietf-smime-ira-00.txt
> 
> The first one describes a problem, and the second one defines 
> a solution 
> for this problem.  I would expect the first one to be published an 
> Informational RFC and the second to be published as a 
> Standards Track RFC.
> 
> Russ
> 

Date: Thu, 25 Oct 2001 15:25:24 -0700
To: "Daniel Brown" <[email-masked]>, "Housley, Russ" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: sender-auth and ira
Cc: [email-masked]
Sender: [email-masked]

At 3:57 PM -0400 10/25/01, Daniel Brown wrote:
>4.  Can the intended-recipients feature be abused?  What if Alice
>signs "I'll pay you $100." with intended recipients of both Bob and
>Carol?  Can Alice abuse this to create confusion and deny obligations?

This is unavoidable and cannot be part of a standard. We cannot 
regulate the content of signed and encrypted messages, nor can we 
regulate the interpretation of that content. We can only regulate the 
signing and encrypting mechanisms.

>6.  Does the intended-recipients feature create too much extra
>bandwidth by including the names of the intended recipients?  If so,
>can there be an option where the intended-recipients are omitted
>from the CMS entity itself but automatically grabbed from the
>TO and CC headers in order computed the signed attributes?

Again, we should not be limiting the solution to RFC 2822 messages. 
CMS is useful for moving lots of kinds of data.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Daniel Brown" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Date: Thu, 25 Oct 2001 15:57:34 -0400
Subject: Re: sender-auth and ira
Sender: [email-masked]

Russ and S/MIME WG,

I have a few minor comments on ira and sender-auth.

1.  AuthenticatedData has built-in resistance to "surreptitious
forwarding" when used properly.  Proper key management includes
static-static DH key agreement, 1-Pass ECMQV or previously distributed
symmetric keys.  In such cases, the AuthenticatedData will have a
"rid" field identifying the recipient's public key or "keyIdentifier"
field identifying the recipient's previously distributed symmetric
key.  This field is enough to ensure that only the recipient
identified can authenticate the message.  If Bob forwards Alice's
AuthenticatedData to Carol, Carol will be notified that the
"Authentication Failed".  This is a stronger notice than "Valid
signature, but you are not an intended recipient".  So, I think it would
be redundant to include all the TO: and CC: names as
intended-recipient authenticated attributes.  (But i-r signed
attributes are fine.)

2.  In the case of BCC, can't "surreptitious forwarding" still be
prevented by sending an individual CMS entity to each BCC
recipients, distinct from the one common CMS entity sent to
all the TO and CC recipients, as would be done normally?
Say Carol is on a BCC list.  Then she receives an individaul
copy of the message, with an individaul CMS object.  The CMS
can be a SignedData and include Carol as an intended-recipient
signed attribute or an AuthenticatedData.  Carol will be assured
that there is no surreptitious forwarding because she is an i-r or
it is a valid auth-data, won't she?

3.  Surreptitious forwarding is quite different from non-repudiation.
If true repudiation is wanted, then SignedData should be avoided.
Even if Alice uses Bob's public key to encrypt the contents before
signing it, Alice can't deny her signature on the ciphertext and Bob
can reveal the plaintext.  With many algorithms, it is possible to
verify that ciphertext is public-key encryption of the plaintext using
Bob's public key.  Bob does not have to reveal his private key, just
the plaintext and perhaps a one-time salt-value.  To completely avoid
non-repudiation, AuthenticatedData should be used instead.

4.  Can the intended-recipients feature be abused?  What if Alice
signs "I'll pay you $100." with intended recipients of both Bob and
Carol?  Can Alice abuse this to create confusion and deny obligations?

6.  Does the intended-recipients feature create too much extra
bandwidth by including the names of the intended recipients?  If so,
can there be an option where the intended-recipients are omitted
from the CMS entity itself but automatically grabbed from the
TO and CC headers in order computed the signed attributes?

Thanks,

Dan

Date: Thu, 25 Oct 2001 09:36:11 -0700
To: "Housley, Russ" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: sender-auth and ira
Sender: [email-masked]

At 10:04 AM -0400 10/25/01, Housley, Russ wrote:
>Two I-Ds were posted, and I have not seen a single comment on them. 
>I hope this message starts a dialogue.

Success. :-)

>The two I-Ds are:
>	draft-ietf-smime-sender-auth-00.txt
>	draft-ietf-smime-ira-00.txt
>
>The first one describes a problem, and the second one defines a 
>solution for this problem.  I would expect the first one to be 
>published an Informational RFC and the second to be published as a 
>Standards Track RFC.

The first draft (sender-auth) defines the problem with a lot of 
hyperbole. The second draft (ira) defines the problem much better. I 
would object to the first draft being moved even to Informational 
status unless:

- it was significantly shortened

- more emphasis was put on how to avoid the problem without protocol 
changes ("If Alice puts Bob's name in the first line of the 
message..." and "If the purchase order has the intended recipient's 
name in it")

- it is stated that the damage that is done by the recipient's 
carelessness is mostly theoretical and cannot happen when there is 
intended addressing information in the content

The solution in the ira draft is much better than the solution in the 
sender-auth draft in that it applies to things other than RFC 2822 
messages. It seems likely that the sender-auth proposal will become 
non-interoperable when there are many RFC 2822 headers with 
recipients in them (such as two To: headers) and with things like 
header folding. I think the ira draft stands on its own with the 
problem description and solution.

Both drafts would be a lot clearer if they said "sign then encrypt" 
instead of "sign and encrypt". The word "and" does not mean "then" in 
most languages, and doesn't necessarily mean it in English.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 Oct 2001 18:10:54 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: sender-auth and ira
Sender: [email-masked]

here a bit:

summary: 

- having a such an attribute for CMS does not seem a useless idea. 

- I am not sure about the profiles about how to use this attribute in an S/MIME
  context. 

details:

> The two I-Ds are:
> 	draft-ietf-smime-sender-auth-00.txt

   "4.2  Symmetric-Key Semantics" 

This is only applied to a mode between TWO participants, and not
to a mode of one sender and several recipients. If a shared key
is used among several then no recipients is sure who has actually 
created the message. (If a symmetric key is used for each pair, then
multiple messages are necessary, see also the comment about bcc later).

Or, it isn't clear to me that: 

" Users tacitly expect public-key file-encryption to offer the same security
  semantics that a symmetric key offers. "

in a context of 1-to-n communication.  

---

     * If the recipient's name doesn't appear in the signed attribute
       listing the intended recipients, then the recipient's software
       must inform the recipient that there is a security problem:
       the author apparently didn't intend the document for this
       recipient's eyes.

I would agree to say : 'the signer did not explicitely indicate 
that this is intended for the recipient's eyes (and the recipient
may have to deduce this information otherwise).  

> 	draft-ietf-smime-ira-00.txt

Section 3.0 sentence 2 and 3 should be moved to the end of the section
where one talks about usage in the context of S/MIME. 

Or, a better separation of the definition of this attribut and its
usage in an S/MIME context should be made. 

I am not sure whether I support not including BCCs. This should go
into a security consideration section. The problem is similar of
what happens in standard bcc: processing. It is up to the sending
system to create separate messages which may for example include
one bcc: header for each of the recipients.. similar for S/MIME
envelopes for BCCs, ...  

Anyway, a possible and cost intensive solution is to have separate
copies with bccs, signed individually, etc. why should one exclude
this. 

Date: Thu, 25 Oct 2001 10:04:56 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: sender-auth and ira
Sender: [email-masked]

S/MIME WG:

Two I-Ds were posted, and I have not seen a single comment on them.  I hope 
this message starts a dialogue.

The two I-Ds are:
	draft-ietf-smime-sender-auth-00.txt
	draft-ietf-smime-ira-00.txt

The first one describes a problem, and the second one defines a solution 
for this problem.  I would expect the first one to be published an 
Informational RFC and the second to be published as a Standards Track RFC.

Russ

From: "Bonatti, Chris" <[email-masked]>
To: "Musy Michel-P28089" <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>, <[email-masked]>
Subject: RE: WG Last Call: x400transport and x400wrap
Date: Tue, 23 Oct 2001 15:52:56 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Michel,

   Not exactly, but close.  The "encrypted body" referred to in step 4 is
the encryptedContent field of the encryptedContentInfo.  However, I think
your comment still applies.  I would suggest that the parenthetical phrase
in step 5 should be replaced with "(the entire EnvelopedData structure)".

   Please contact me if you have further questions.

Chris Bonatti

 -----------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.  |
 |  Christopher D. Bonatti              Tel: 301-208-2349  |
 |  Principal Engineer                  Fax: 301-208-2379  |
 -----------------------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Musy Michel-P28089
Sent: Monday, October 22, 2001 13:27
To: Housley, Russ; [email-masked]
Subject: RE: WG Last Call: x400transport and x400wrap

Request for Clarification:

The following steps decribe how to build a tripple wrapped message
with an X.400 content. Is the "encrypted body" only the
encryptedContentInfo?
This is my understanding.
If so, should Step 4 after the text "This is called the "encrypted body"."
specify that the enveloped data structure is built?
And shouln't Step 5 instead of referencing "(the encrypted body)", should
reference the envelope data structure?

Attached below Step 4 and Step 5 as they appear in the document.
I understand that the "encrypted body" is not the whole envelope
data but the whole envelope data structure should be signed.
Please clarify if there is something that I misunderstood.

Michel
email: [email-masked]

------------------- From x400wrap-04 -------------------------

Step 4. Encrypt the result of step 3 as a single block. The
EnvelopedData encryptedContentInfo contentType MUST be set to
id-signedData. This is called the "encrypted body".

Step 5. Using the same logic as in step 2 and 3 above, sign the result
of step 4 (the encrypted body) as a single block. The SignedData
encapContentInfo eContentType MUST be set to id-envelopedData. The outer
SignedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Monday, October 22, 2001 7:21 AM
To: [email-masked]
Subject: WG Last Call: x400transport and x400wrap

Dear WG Members:

We have been in WG Last Call on these two documents for quite some
time.  The WG Last Call on x400wrap was originally scheduled to end on 14
September, and the WG Last Call for x400transport was originally scheduled
to end on 4 October.  The authors believe that all comments have been
resolved in the current versions.  I believe that it is appropriate to
progress these two documents at the same time.

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-04.txt
	Date		: 19-Oct-01

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-04.txt
	Date		: 27-Aug-01

Please review them to confirm that requested changes have been
incorporated.  Unless traffic on the mail list indicates otherwise, I will
send these to the Security Area Directors on Friday, 26 October.  So, if
you have concerns, please make them known by Thursday.

Russ

------=_NextPart_000_0002_01C15BDA.C706BBF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

AAAA

------=_NextPart_000_0002_01C15BDA.C706BBF0--

From: "Daniel Brown" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Date: Mon, 22 Oct 2001 14:47:50 -0400
Subject: Re: Questions on AuthenticatedData
Sender: [email-masked]

--0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Jim,

I suggest the following answers to your questions, in the case
of HMAC-SHA1 and CMS-3DES-WRAP.

1.  We should specify the HMAC-SHA1 key size to be 160 bits (the
strength of HMAC-SHA1).

2.  When wrapping with 3DES, a 192-bit key is expected, so pad with
the HMAC-SHA1 key 32 zero bits (which gives an equivalent 192-bit
HMAC-SHA1 key).

3. No.

These answers need adjustments for other key wrap and
MAC algorithms.

Reasoning and further details are given below.

Recall that, as Simon, Paul and I noted in our Internet-Draft "Use of
ECC Algorithms in S/MIME", if AuthenticatedData uses two or more
RecipinientInfo's, then there is a serious problem.  Say R1 and
R2 are the recipients, the message is M and the MAC key is K.  Since
R2 receives K, receiver R2 can use it to compute MAC_K(M') for a bogus
message M' and then send a bogus AuthenticatedData to R1, using the
Wrap_R1(K) already present in the original AuthenticatedData.  R1
would think M' originated from the sender even though it originated
from R2.  Once R2 sees K and Wrap_R1(K), R2 can repeat this attack as
often as necessary.  Thus, our I-D recommends just one RecipientInfo
per AuthenticatedData.

Now, a similar attack might apply if a weak MAC key is used.  In an
extreme case, suppose a sender S sends an AuthenticatedData to a
receiver R using a 1-bit MAC key.  An adversary A knowing about the
1-bit key can guess the MAC key, confirm its guess, and then launch
the above attack.  This works no matter how strong the key management
and wrap algorithms, because A knows once K and Wrap_R(K), A can send
any message to the receiver R in an AuthenticatedData appearing to be
from S.

If 10-bit MAC key is used, then the attacker has to guess 512 MAC keys
on average.  If a 40-bit MAC key is used, the sender must guess 2^39
MAC keys on average.  Although it is probably impractical, once the
guess is made, the attacker can forge as many AuthenticatedData's as
desired.  Thus the effective strength of AuthenticatedData is limited
by the smallest MAC key size used.

In fact, in the multi-user setting where 40-bit MAC keys are used,
after about 2^20 messages, one expects identical MAC keys to have been
used.  This might also lead to problems.

Thus, I think a minimum HMAC-SHA1 key length should be set.  Perhaps
80 bits is enough, but I don't know.  Clearly, 160 bits would be
safer.

The minimum key size should be a MUST or SHOULD for the sender.
I realize some implementations may prefer a 128-bit key generator, but
this might be a little low.

It could be a SHOULD for the receiver, except that one has to be careful about
ascertaining the length of the key.  Suppose the sender selects a
random 160 bit key K, but due to pure chance, the last 8 bits are
zero.  This could happen with 1 in 256 chance.  Should the receiver
reject this because it looks like a small key (152 bits)?  Probably
not.

One possible exception to the minimum could be the following.  If a
key-wrap algorithm Wrap40 only supports 40 bits, then a 40-bit
HMAC-SHA1 K40 could be used.  The guessing attack can still be
launched, but all the forged AuthenticatedData's would contain K40 and
Wrap40(K40).  It does not seem possible to generate Wrap192(K40), so
the attack does not allow forgery of high-strength AuthenticatedData's
(assuming the wrap algorithm is secure).

My preference would be adapt such a Wrap40 to allow wrapping of
longer MAC keys using 40bit encryption.

Finally, larger key sizes would not hurt, but do not seem to help,
according to the RFC on HMAC-SHA1.  Key sizes 193-512 cannot be
wrapped with the current 3DES algorithm, but key sizes 513 and larger
can be because they are hashed to 160 bits first accoring to the
way HMAC-SHA1 is defined.

Thanks,

Dan

"Jim Schaad" <[email-masked]> on 10/07/2001 08:56:58 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Daniel Brown/Certicom)
Subject:  Questions on AuthenticatedData

I have just started an implemenation for AutenticatedData and have the
following questions:

1.  Should we specify a suggested size for the randomly generated secret
to be used for HMAC-SHA1?  (The size for HMAC-3DES is fixed at the size
of a 3DES key.)

2.  What key wrap algorithm should I use for wrapping the secret for an
HMAC-SHA1 secret?  I can see myself generating a 512 bit secret for the
MAC operation, now I need to wrap it in a 3DES, RC2 or AES key.  What is
the proper way of doing this?

3.  Does the answer for 2 imply that we want the lengths for 1 to be the
length of a defined content encrytion algorithm key?

Jim

--0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF
Content-type: application/octet-stream; 
	name="att1.eml"
Content-Disposition: attachment; filename="att1.eml"
Content-transfer-encoding: base64

--0__=7v82HNHnA5HtZDOgLk77uD0YVdnvRpGQIDllJTiJzIgFAkyg5HwgZBfF--

From: Musy Michel-P28089 <[email-masked]>
To: "Housley, Russ" <[email-masked]>, [email-masked]
Subject: RE: WG Last Call: x400transport and x400wrap
Date: Mon, 22 Oct 2001 10:27:24 -0700
Sender: [email-masked]

Request for Clarification:

The following steps decribe how to build a tripple wrapped message
with an X.400 content. Is the "encrypted body" only the encryptedContentInfo?
This is my understanding.
If so, should Step 4 after the text "This is called the "encrypted body"."
specify that the enveloped data structure is built?
And shouln't Step 5 instead of referencing "(the encrypted body)", should
reference the envelope data structure?

Attached below Step 4 and Step 5 as they appear in the document.
I understand that the "encrypted body" is not the whole envelope
data but the whole envelope data structure should be signed. 
Please clarify if there is something that I misunderstood.

Michel
email: [email-masked]

------------------- From x400wrap-04 -------------------------

Step 4. Encrypt the result of step 3 as a single block. The
EnvelopedData encryptedContentInfo contentType MUST be set to
id-signedData. This is called the "encrypted body".

Step 5. Using the same logic as in step 2 and 3 above, sign the result
of step 4 (the encrypted body) as a single block. The SignedData
encapContentInfo eContentType MUST be set to id-envelopedData. The outer
SignedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Monday, October 22, 2001 7:21 AM
To: [email-masked]
Subject: WG Last Call: x400transport and x400wrap

Dear WG Members:

We have been in WG Last Call on these two documents for quite some 
time.  The WG Last Call on x400wrap was originally scheduled to end on 14 
September, and the WG Last Call for x400transport was originally scheduled 
to end on 4 October.  The authors believe that all comments have been 
resolved in the current versions.  I believe that it is appropriate to 
progress these two documents at the same time.

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-04.txt
	Date		: 19-Oct-01

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-04.txt
	Date		: 27-Aug-01

Please review them to confirm that requested changes have been 
incorporated.  Unless traffic on the mail list indicates otherwise, I will 
send these to the Security Area Directors on Friday, 26 October.  So, if 
you have concerns, please make them known by Thursday.

Russ

Date: Mon, 22 Oct 2001 10:20:49 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: WG Last Call: x400transport and x400wrap
Sender: [email-masked]

Dear WG Members:

We have been in WG Last Call on these two documents for quite some 
time.  The WG Last Call on x400wrap was originally scheduled to end on 14 
September, and the WG Last Call for x400transport was originally scheduled 
to end on 4 October.  The authors believe that all comments have been 
resolved in the current versions.  I believe that it is appropriate to 
progress these two documents at the same time.

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-04.txt
	Date		: 19-Oct-01

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-04.txt
	Date		: 27-Aug-01

Please review them to confirm that requested changes have been 
incorporated.  Unless traffic on the mail list indicates otherwise, I will 
send these to the Security Area Directors on Friday, 26 October.  So, if 
you have concerns, please make them known by Thursday.

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x400transport-04.txt
Date: Mon, 22 Oct 2001 07:04:16 -0400
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		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-04.txt
	Pages		: 
	Date		: 19-Oct-01
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-x400transport-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-x400transport-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-x400transport-04.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-password-06.txt
Date: Mon, 22 Oct 2001 07:04:05 -0400
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		: Password-based Encryption for SMS
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-06.txt
	Pages		: 
	Date		: 19-Oct-01
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-password-06.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Subject: RFC 3183 on Domain Security Services using S/MIME
Cc: [email-masked], [email-masked]
Date: Fri, 19 Oct 2001 15:59:55 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3183

        Title:	    Domain Security Services using S/MIME
        Author(s):  T. Dean, W. Ottaway
        Status:     Experimental
	Date:       October 2001
        Mailbox:    [email-masked],
                    [email-masked] 
        Pages:      24
        Characters: 57129
        SeeAlso/Updates/Obsoletes:    None

        I-D Tag:    draft-ietf-smime-domsec-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt

This document describes how the S/MIME (Secure/Multipurpose Internet
Mail Extensions) protocol can be processed and generated by a number
of components of a communication system, such as message transfer
agents, guards and gateways to deliver security services.  These
services are collectively referred to as 'Domain Security Services'.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3183

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3185 on Reuse of CMS Content Encryption Keys
Cc: [email-masked], [email-masked]
Date: Fri, 19 Oct 2001 15:56:46 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3185

        Title:	    Reuse of CMS Content Encryption Keys
        Author(s):  S. Farrell, S. Turner
        Status:     Standards Track
	Date:       October 2001
        Mailbox:    [email-masked], [email-masked]
        Pages:      10
        Characters: 20404
        SeeAlso/Updates/Obsoletes:    None

        I-D Tag:    draft-ietf-smime-rcek-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3185.txt

This document describes a way to include a key identifier in a CMS
(Cryptographic Message Syntax) enveloped data structure, so that the
content encryption key can be re-used for further enveloped data
packets.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3185

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3126 on Electronic Signature Formats
Cc: [email-masked], [email-masked]
Date: Fri, 19 Oct 2001 15:51:23 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3126

        Title:	    Electronic Signature Formats for long term
                    electronic signatures
        Author(s):  D. Pinkas, J. Ross, N. Pope
        Status:     Informational
	Date:       September 2001
        Mailbox:    [email-masked], Denis.Pinkas @bull.net,
                    [email-masked], [email-masked]
        Pages:      84
        Characters: 175886
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-esformats-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3126.txt

This document defines the format of an electronic signature that can
remain valid over long periods.  This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).
 
The format can be considered as an extension to RFC 2630 and RFC 2634,
where, when appropriate additional signed and unsigned attributes have
been defined.
 
The contents of this Informational RFC is technically equivalent to
ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3126

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3125 on Electronic Signature Policies
Cc: [email-masked], [email-masked]
Date: Fri, 19 Oct 2001 15:50:23 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3125

        Title:	    Electronic Signature Policies
        Author(s):  J. Ross, D. Pinkas, N. Pope
        Status:     Experimental
	Date:       September 2001
        Mailbox:    [email-masked], [email-masked],
                    [email-masked] 
        Pages:      43
        Characters: 95505
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-espolicies-00.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3125.txt

This document defines signature policies for electronic signatures.
A signature policy is a set of rules for the creation and validation
of an electronic signature, under which the validity of signature can
be determined.  A given legal/contractual context may recognize a
particular signature policy as meeting its requirements.
 
A signature policy has a globally unique reference, which is bound to
an electronic signature by the signer as part of the signature
calculation.
 
The signature policy needs to be available in human readable form so
that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied.
 
To allow for the automatic processing of an electronic signature
another part of the signature policy specifies the electronic
rules for the creation and validation of the electronic signature in
a computer processable form.  In the current document the format of
the signature policy is defined using ASN.1.
 
The contents of this document is based on the signature policy defined
in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).  Individual copies
of this ETSI deliverable can be downloaded from http://www.etsi.org.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3125

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3183 on Domain Security Services using S/MIME
Cc: [email-masked], [email-masked]
From: RFC Editor <[email-masked]>
Date: Wed, 17 Oct 2001 14:48:21 -0400
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 3183

        Title:	    Domain Security Services using S/MIME
        Author(s):  T. Dean, W. Ottaway
        Status:     Experimental
	Date:       October 2001
        Mailbox:    [email-masked],
                    [email-masked] 
        Pages:      24
        Characters: 57129
        SeeAlso/Updates/Obsoletes:    None

        I-D Tag:    draft-ietf-smime-domsec-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt

This document describes how the S/MIME (Secure/Multipurpose Internet
Mail Extensions) protocol can be processed and generated by a number
of components of a communication system, such as message transfer
agents, guards and gateways to deliver security services.  These
services are collectively referred to as 'Domain Security Services'.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

----- End Included Message -----

----------
X-Sun-Data-Type: Multipart
X-Sun-Content-Length: 490
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 22

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

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

RETRIEVE: rfc
DOC-ID: rfc3183

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3126 on Electronic Signature Formats
Cc: [email-masked], [email-masked]
From: RFC Editor <[email-masked]>
Date: Wed, 17 Oct 2001 14:47:53 -0400
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 3126

        Title:	    Electronic Signature Formats for long term
                    electronic signatures
        Author(s):  D. Pinkas, J. Ross, N. Pope
        Status:     Informational
	Date:       September 2001
        Mailbox:    [email-masked], Denis.Pinkas @bull.net,
                    [email-masked], [email-masked]
        Pages:      84
        Characters: 175886
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-esformats-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3126.txt

This document defines the format of an electronic signature that can
remain valid over long periods.  This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).
 
The format can be considered as an extension to RFC 2630 and RFC 2634,
where, when appropriate additional signed and unsigned attributes have
been defined.
 
The contents of this Informational RFC is technically equivalent to
ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

----- End Included Message -----

----------
X-Sun-Data-Type: Multipart
X-Sun-Content-Length: 490
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 22

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

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

RETRIEVE: rfc
DOC-ID: rfc3126

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3125 on Electronic Signature Policies
Cc: [email-masked], [email-masked]
From: RFC Editor <[email-masked]>
Date: Wed, 17 Oct 2001 14:47:48 -0400
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 3125

        Title:	    Electronic Signature Policies
        Author(s):  J. Ross, D. Pinkas, N. Pope
        Status:     Experimental
	Date:       September 2001
        Mailbox:    [email-masked], [email-masked],
                    [email-masked] 
        Pages:      43
        Characters: 95505
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-espolicies-00.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3125.txt

This document defines signature policies for electronic signatures.
A signature policy is a set of rules for the creation and validation
of an electronic signature, under which the validity of signature can
be determined.  A given legal/contractual context may recognize a
particular signature policy as meeting its requirements.
 
A signature policy has a globally unique reference, which is bound to
an electronic signature by the signer as part of the signature
calculation.
 
The signature policy needs to be available in human readable form so
that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied.
 
To allow for the automatic processing of an electronic signature
another part of the signature policy specifies the electronic
rules for the creation and validation of the electronic signature in
a computer processable form.  In the current document the format of
the signature policy is defined using ASN.1.
 
The contents of this document is based on the signature policy defined
in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).  Individual copies
of this ETSI deliverable can be downloaded from http://www.etsi.org.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

----- End Included Message -----

----------
X-Sun-Data-Type: Multipart
X-Sun-Content-Length: 490
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 22

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

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

RETRIEVE: rfc
DOC-ID: rfc3125

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

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

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3185 on Reuse of CMS Content Encryption Keys
Cc: [email-masked], [email-masked]
Date: Tue, 16 Oct 2001 13:46:22 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3185

        Title:	    Reuse of CMS Content Encryption Keys
        Author(s):  S. Farrell, S. Turner
        Status:     Standards Track
	Date:       October 2001
        Mailbox:    [email-masked], [email-masked]
        Pages:      10
        Characters: 20404
        SeeAlso/Updates/Obsoletes:    None

        I-D Tag:    draft-ietf-smime-rcek-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3185.txt

This document describes a way to include a key identifier in a CMS
(Cryptographic Message Syntax) enveloped data structure, so that the
content encryption key can be re-used for further enveloped data
packets.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3185

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

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

--OtherAccess--
--NextPart--

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: WG Last Call: cmsalg
Date: Mon, 15 Oct 2001 15:50:23 -0400
Sender: [email-masked]

Magnus,

I still agree with Jim Schaad's original point that the S/MIME specs should
import the certificate, CRL and attribute certificate ASN.1 syntaxes (and
components thereof) from the ASN.1 modules in the PKIX specs since the PKIX
working group is the authoritative source for the IETF regarding the
specification of those objects.

It would be great news if all of the ITU-T Recommendations were freely
available.  However, the  ITU-T web page
<http://www.itu.int/ITU-T/publications/index.html> states:

"ITU-T Recommendations in Force

These are available for purchase and published in different forms -
individual paper fascicles, individual electronic files, entire collection
on CD-ROM, through yearly on-line subscription to all Recommendations in
force."

Also, in a message sent to the PKIX mail list in May 2001, Hoyt Kesterson
stated: "ITU is allowing any three recommendations to be downloaded at no
cost from their server."  I have never seen a statement that all of the
ITU-T Recommendations were freely available.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Magnus Nystrom [mailto:[email-masked]]
Sent: Friday, October 12, 2001 5:23 AM
To: [email-masked]
Subject: RE: WG Last Call: cmsalg

Actually, it turns out that they indeed are freely available:

http://www.itu.int/ITU-T/asn1/database/itu-t/x/index.html

Many Thanks to Hoyt Kesterson for informing me about this. Hoyt
mentioned to me that the database perhaps is not complete yet; a quick
look however indicates that all needed v3 modules are in place.

So, perhaps S/MIME could reference these modules after all...

BR,
-- Magnus

To: IETF-Announce: ;
Subject: RFC 3183 on Domain Security Services using S/MIME
Cc: [email-masked], [email-masked]
Date: Fri, 12 Oct 2001 16:26:33 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3183

        Title:	    Domain Security Services using S/MIME
        Author(s):  T. Dean, W. Ottaway
        Status:     Experimental
	Date:       October 2001
        Mailbox:    [email-masked],
                    [email-masked] 
        Pages:      24
        Characters: 57129
        SeeAlso/Updates/Obsoletes:    None

        I-D Tag:    draft-ietf-smime-domsec-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt

This document describes how the S/MIME (Secure/Multipurpose Internet
Mail Extensions) protocol can be processed and generated by a number
of components of a communication system, such as message transfer
agents, guards and gateways to deliver security services.  These
services are collectively referred to as 'Domain Security Services'.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3183

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

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

--OtherAccess--
--NextPart--

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 12 Oct 2001 12:51:33 -0400
Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
Sender: [email-masked]

Bill & Blake:

I would prefer that a encrypt-only-DOMSEC implementation preserve any 
signature that is already in place, but not add an empty signature wrapper.

I look forward to the harmonized draft.  Blake, when the draft is ready, 
please post it as draft-ietf-smime-enc-only-domsec-00.txt.

Russ

At 03:36 PM 10/12/2001 +0100, William Ottaway wrote:

>Hi Blake,
>
>The DOMSEC draft does not require triple-wrapping it only states that it is
>supported. A message that only follows the DOMSEC encryption rules, i.e. no
>added signature, would be DOMSEC compliant.
>
>The empty signature is only a requirement when you are applying a DOMSEC
>signature to a message that does not already have a signature. This rule was
>added for backward compatibility. Since you are only encrypting this is not
>an issue for you. If you were to support signatures then your system may
>enforce that a signature is always present before a DOMSEC signature is
>applied or you could have a profile of DOMSEC that ignores the empty
>signature rule, assuming backwards compatibility is not an issue.
>
>Bill.
>
>____________________________________________________
>  William Ottaway BSc Hons CEng MBCS,
>  Woodward B009,
>  QinetiQ                      Tel: +44 (0) 1684 894079
>  Malvern Technology Centre,   Fax: +44 (0) 1684 896660
>  St. Andrews Road,            email: [email-masked]
>  Malvern,
>  Worcs,
>  WR14 3PS
>
>  All opinions are my own.
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Blake Ramsdell
> > Sent: 04 October 2001 21:00
> > To: 'William Ottaway'; [email-masked]
> > Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
> >
> >
> >
> > Bill, thanks very much for doing this summary.
> >
> > One thing that we were initially concerned about was that there was a
> > requirement for triple-wrapping and/or an empty signature layer
> > (SignedData
> > with no SignerInfos).  If this requirement is gone, then I believe we can
> > simply make our document an "encrypting-only" profile for DOMSEC.
> >
> > I propose that our current document continue to live, but with
> > the following
> > changes:
> >
> > 1. Refer to DOMSEC in the relevant places in our draft
> >
> > 2. Remove the language about the email address in the
> > certificate, and refer
> > to DOMSEC for this
> >
> > 3. Clarify that the additions that we have specified for handling
> > subdomains, etc. are in addition to DOMSEC (and thus the meat of this
> > profile)
> >
> > The only impact for any existing implementations of our
> > specification would
> > therefore be the recognition of the DOMSEC-specified email address
> > (domain-confidentiality-authority) as opposed to the smg_encryptor email
> > address that we originally specified in our draft.
> >
> > Blake
> >
> > -----Original Message-----
> > From: William Ottaway [mailto:[email-masked]]
> > Sent: Friday, September 21, 2001 6:42 AM
> > To: [email-masked]
> > Cc: Blake Ramsdell
> > Subject: DOMSEC and S/MIME Gateway Protocol comparison
> >
> >
> >
> >
> > At the S/MIME WG meeting in London I was tasked to provide a comparison
> > between DOMSEC and the S/MIME Gateway Protocol
> > (draft-ramsdell-enc-smime-gateway-00.txt) in order to start a
> > discussion on
> > whether the gateway draft should be progressed and if so how
> > would it relate
> > to DOMSEC.
> >
> >
> > DOMSEC Summary: -
> >
> > 1) Encryption/Decryption and signing.
> >
> > 2) Defines naming conventions.
> >
> > 3) Defines signature types.
> >
> > 4) Defines membership of a domain.
> >
> > 5) Defines rules for domain signature generation and verification.
> >
> > 6) States how domain encryption/decryption is achieved.
> >
> > 7) Defines domain signature application rules when sending to mail list
> > agents.
> >
> >
> > Gateway Summary: -
> >
> > 1) Encryption/Decryption only.
> >
> > 2) Uses same notation of domain "membership" as DOMSEC.
> >
> > 3) Introduces its own naming convention for the encrypting entities domain
> > certificate,    smg_encryptor@domain. DOMSEC defines
> > domain-confidentiality-authority@domain.
> >
> > 4) Introduces a mechanism for identifying multiple domains handled by the
> > gateway. They can be listed in a single certificate or in multiple
> > certificates.
> >
> > 5) Introduces a rule for deciding which recipient domain
> > certificate must be
> > used.
> >
> > 6) Introduces a rule on how the gateway recognises that a message requires
> > encryption (encrypt if have a certificate for the recipients domain).
> >
> > 7) Introduces a rule on when the gateway should decrypt a message
> > (when the
> > gateways public key has been used to encrypt)
> >
> >
> > My view: -
> >
> > DOMSEC defines mechanisms for domain signing and encrypting with out
> > specifying mechanisms or rules that are deemed local to the
> > installation. It
> > is hoped that domain signing and encryption implementations will be
> > compliant with DOMSEC. It is expected that individual installations will
> > provide extra local mechanisms and rules in support of DOMSEC, for example
> > how to decide on which certificate to use, how to decide on whether
> > encryption is required, how certificates are retrieved, whether a domain
> > signature is stripped off before forwarding to the local
> > recipient, whether
> > encryption between the domain boundary and the local recipient is
> > required,
> > etc.
> >
> > The Gateway draft defines mechanisms that are already defined in DOMSEC,
> > such as encryption and naming notation. It also defines
> > mechanisms that may
> > differ between implementations, such as domains that are handled by the
> > gateway may be listed in a single or multiple certificate and
> > rules on which
> > recipient certificate to use when encrypting.
> >
> > I propose that the Gateway draft should be a profile of DOMSEC. Therefore,
> > it should support encryption/decryption as specified in DOMSEC and the
> > DOMSEC naming convention. The Gateway draft would contain those features
> > local to this implementation such as points 4 - 7 in the gateway summary.
> >
> > Bill
> > ____________________________________________________
> >  William Ottaway BSc Hons CEng MBCS,
> >  Woodward B009,
> >  QinetiQ                      Tel: +44 (0) 1684 894079
> >  Malvern Technology Centre,   Fax: +44 (0) 1684 896660
> >  St. Andrews Road,            email: [email-masked]
> >  Malvern,
> >  Worcs,
> >  WR14 3PS
> >
> >  All opinions are my own.
> >
> >
> >

From: "William Ottaway" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
Date: Fri, 12 Oct 2001 15:36:28 +0100
Importance: Normal
Sender: [email-masked]

Hi Blake,

The DOMSEC draft does not require triple-wrapping it only states that it is
supported. A message that only follows the DOMSEC encryption rules, i.e. no
added signature, would be DOMSEC compliant.

The empty signature is only a requirement when you are applying a DOMSEC
signature to a message that does not already have a signature. This rule was
added for backward compatibility. Since you are only encrypting this is not
an issue for you. If you were to support signatures then your system may
enforce that a signature is always present before a DOMSEC signature is
applied or you could have a profile of DOMSEC that ignores the empty
signature rule, assuming backwards compatibility is not an issue.

Bill.

____________________________________________________
 William Ottaway BSc Hons CEng MBCS,
 Woodward B009,
 QinetiQ                      Tel: +44 (0) 1684 894079
 Malvern Technology Centre,   Fax: +44 (0) 1684 896660
 St. Andrews Road,            email: [email-masked]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Blake Ramsdell
> Sent: 04 October 2001 21:00
> To: 'William Ottaway'; [email-masked]
> Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
>
>
>
> Bill, thanks very much for doing this summary.
>
> One thing that we were initially concerned about was that there was a
> requirement for triple-wrapping and/or an empty signature layer
> (SignedData
> with no SignerInfos).  If this requirement is gone, then I believe we can
> simply make our document an "encrypting-only" profile for DOMSEC.
>
> I propose that our current document continue to live, but with
> the following
> changes:
>
> 1. Refer to DOMSEC in the relevant places in our draft
>
> 2. Remove the language about the email address in the
> certificate, and refer
> to DOMSEC for this
>
> 3. Clarify that the additions that we have specified for handling
> subdomains, etc. are in addition to DOMSEC (and thus the meat of this
> profile)
>
> The only impact for any existing implementations of our
> specification would
> therefore be the recognition of the DOMSEC-specified email address
> (domain-confidentiality-authority) as opposed to the smg_encryptor email
> address that we originally specified in our draft.
>
> Blake
>
> -----Original Message-----
> From: William Ottaway [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 6:42 AM
> To: [email-masked]
> Cc: Blake Ramsdell
> Subject: DOMSEC and S/MIME Gateway Protocol comparison
>
>
>
>
> At the S/MIME WG meeting in London I was tasked to provide a comparison
> between DOMSEC and the S/MIME Gateway Protocol
> (draft-ramsdell-enc-smime-gateway-00.txt) in order to start a
> discussion on
> whether the gateway draft should be progressed and if so how
> would it relate
> to DOMSEC.
>
>
> DOMSEC Summary: -
>
> 1) Encryption/Decryption and signing.
>
> 2) Defines naming conventions.
>
> 3) Defines signature types.
>
> 4) Defines membership of a domain.
>
> 5) Defines rules for domain signature generation and verification.
>
> 6) States how domain encryption/decryption is achieved.
>
> 7) Defines domain signature application rules when sending to mail list
> agents.
>
>
> Gateway Summary: -
>
> 1) Encryption/Decryption only.
>
> 2) Uses same notation of domain "membership" as DOMSEC.
>
> 3) Introduces its own naming convention for the encrypting entities domain
> certificate,    smg_encryptor@domain. DOMSEC defines
> domain-confidentiality-authority@domain.
>
> 4) Introduces a mechanism for identifying multiple domains handled by the
> gateway. They can be listed in a single certificate or in multiple
> certificates.
>
> 5) Introduces a rule for deciding which recipient domain
> certificate must be
> used.
>
> 6) Introduces a rule on how the gateway recognises that a message requires
> encryption (encrypt if have a certificate for the recipients domain).
>
> 7) Introduces a rule on when the gateway should decrypt a message
> (when the
> gateways public key has been used to encrypt)
>
>
> My view: -
>
> DOMSEC defines mechanisms for domain signing and encrypting with out
> specifying mechanisms or rules that are deemed local to the
> installation. It
> is hoped that domain signing and encryption implementations will be
> compliant with DOMSEC. It is expected that individual installations will
> provide extra local mechanisms and rules in support of DOMSEC, for example
> how to decide on which certificate to use, how to decide on whether
> encryption is required, how certificates are retrieved, whether a domain
> signature is stripped off before forwarding to the local
> recipient, whether
> encryption between the domain boundary and the local recipient is
> required,
> etc.
>
> The Gateway draft defines mechanisms that are already defined in DOMSEC,
> such as encryption and naming notation. It also defines
> mechanisms that may
> differ between implementations, such as domains that are handled by the
> gateway may be listed in a single or multiple certificate and
> rules on which
> recipient certificate to use when encrypting.
>
> I propose that the Gateway draft should be a profile of DOMSEC. Therefore,
> it should support encryption/decryption as specified in DOMSEC and the
> DOMSEC naming convention. The Gateway draft would contain those features
> local to this implementation such as points 4 - 7 in the gateway summary.
>
> Bill
> ____________________________________________________
>  William Ottaway BSc Hons CEng MBCS,
>  Woodward B009,
>  QinetiQ                      Tel: +44 (0) 1684 894079
>  Malvern Technology Centre,   Fax: +44 (0) 1684 896660
>  St. Andrews Road,            email: [email-masked]
>  Malvern,
>  Worcs,
>  WR14 3PS
>
>  All opinions are my own.
>
>
>

Date: Fri, 12 Oct 2001 11:22:48 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Last Call: cmsalg
Sender: [email-masked]

Actually, it turns out that they indeed are freely available:

http://www.itu.int/ITU-T/asn1/database/itu-t/x/index.html

Many Thanks to Hoyt Kesterson for informing me about this. Hoyt
mentioned to me that the database perhaps is not complete yet; a quick
look however indicates that all needed v3 modules are in place.

So, perhaps S/MIME could reference these modules after all...

BR,
-- Magnus

On Thu, 11 Oct 2001, Magnus Nystrom wrote:

> ...though of course X.509 ASN.1 modules are not freely available
> (AFAIK),
>
> Sorry for any confusion,
> -- Magnus
>
> On Thu, 11 Oct 2001, Magnus Nystrom wrote:
>
> > John Pawling wrote:
> >
> > [...]
> > > I agree with Jim Schaad that the S/MIME specs should reference
> > > the ASN.1 modules in the PKIX documents instead of the ITU-T
> > > documents.  The PKIX documents are freely available to all, but the
> > > ITU-T documents are not.
> >
> > This is not true; all ITU-T ASN.1 documents are available at:
> >
> > http://www.itu.int/ITU-T/studygroups/com10/languages/index.html
> >
> > Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL
> > tags), which complicates matters for those using standards-compliant
> > compilers.

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 11 Oct 2001 15:04:59 -0400
Subject: Re: X.509 ASN.1 Modules (was Re: WG Last Call: cmsalg)
Sender: [email-masked]

Aram:

Thanks.  The 1997 version posted here is not the most recent 
version.  While it looks like this site may offer some help in the future, 
it is lagging behind the times.

Russ

>Magnus Nystrom wrote:
> > ...though of course X.509 ASN.1 modules are not freely available
> > (AFAIK),
>
>Surfing the link for the ASN.1 documents, I ran across the following links:
>http://www.itu.int/ITU-T/asn1/database/index.html
>http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/1997/index.html
>
>Enjoy,
>Aram Perez

From: [email-masked]
To: [email-masked]
Subject: X.509 ASN.1 Modules (was Re: WG Last Call: cmsalg)
Date: Thu, 11 Oct 2001 17:28:18 +0000
Reply-To: [email-masked]
Sender: [email-masked]

Magnus Nystrom wrote:

> ...though of course X.509 ASN.1 modules are not freely available
> (AFAIK),

Surfing the link for the ASN.1 documents, I ran across the following links: 
http://www.itu.int/ITU-T/asn1/database/index.html
http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/1997/index.html

Enjoy,
Aram Perez

_________________________________________________
The simple way to read all your emails at ThatWeb
http://www.thatweb.com

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 11 Oct 2001 10:32:22 -0400
Subject: draft-ietf-smime-pkcs1-01.txt
Sender: [email-masked]

Jeff & Marcus:

The S/MIME WG is finished with draft-ietf-smime-pkcs1-01.txt.  This 
document that describes countermeasures to the Million Message Attack (MMA) 
for CMS implementations that support PKCS #1 v1.5.  We want to publish this 
document as an Informational RFC.

	Title		: Preventing the Million Message Attack on CMS
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-pkcs1-01.txt
	Pages		: 5
	Date		: 24-Sep-01
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-pkcs1-01.txt

Russ 

From: "Housley, Russ" <[email-masked]>
To: "Nystrom, Magnus" <[email-masked]>
Cc: [email-masked]
Date: Thu, 11 Oct 2001 09:07:44 -0400
Subject: RE: WG Last Call: cmsalg
Sender: [email-masked]

Magnus:

I think that John was referring to the ASN.1 modules associated with X.509, 
not the ASN.1 specifications themselves.

Russ

At 11:10 AM 10/11/2001 +0200, Magnus Nystrom wrote:

>John Pawling wrote:
>
>[...]
> > I agree with Jim Schaad that the S/MIME specs should reference
> > the ASN.1 modules in the PKIX documents instead of the ITU-T
> > documents.  The PKIX documents are freely available to all, but the
> > ITU-T documents are not.
>
>This is not true; all ITU-T ASN.1 documents are available at:
>
>http://www.itu.int/ITU-T/studygroups/com10/languages/index.html
>
>Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL
>tags), which complicates matters for those using standards-compliant
>compilers.
>
>BR,
>-- Magnus

Date: Thu, 11 Oct 2001 14:29:19 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Last Call: cmsalg
Sender: [email-masked]

...though of course X.509 ASN.1 modules are not freely available
(AFAIK),

Sorry for any confusion,
-- Magnus

On Thu, 11 Oct 2001, Magnus Nystrom wrote:

> John Pawling wrote:
>
> [...]
> > I agree with Jim Schaad that the S/MIME specs should reference
> > the ASN.1 modules in the PKIX documents instead of the ITU-T
> > documents.  The PKIX documents are freely available to all, but the
> > ITU-T documents are not.
>
> This is not true; all ITU-T ASN.1 documents are available at:
>
> http://www.itu.int/ITU-T/studygroups/com10/languages/index.html
>
> Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL
> tags), which complicates matters for those using standards-compliant
> compilers.

Date: Thu, 11 Oct 2001 11:10:52 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Last Call: cmsalg
Sender: [email-masked]

John Pawling wrote:

[...]
> I agree with Jim Schaad that the S/MIME specs should reference
> the ASN.1 modules in the PKIX documents instead of the ITU-T
> documents.  The PKIX documents are freely available to all, but the
> ITU-T documents are not.

This is not true; all ITU-T ASN.1 documents are available at:

http://www.itu.int/ITU-T/studygroups/com10/languages/index.html

Further, the ASN.1 in PKIX docs is not correct (use of UNIVERSAL
tags), which complicates matters for those using standards-compliant
compilers.

BR,
-- Magnus

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: WG Last Call: cmsalg
Date: Tue, 9 Oct 2001 11:13:29 -0400 
Sender: [email-masked]

All,

I vote for option 3: "Use PKIX for everything except for v1 attribute
certificates; define v1 attribute certificates in the rfc2630bis appendix." 

I agree with Jim Schaad that the S/MIME specs should reference the ASN.1
modules in the PKIX documents instead of the ITU-T documents.  The PKIX
documents are freely available to all, but the ITU-T documents are not. 

To my knowledge, RFC 2630 is the only IETF spec that uses the v1 attribute
certificate syntax, so I agree with Russ Housley that the v1 attribute
certificate syntax should be included in a rfc2630bis appendix.

The S/MIME Freeware Library can ASN.1 encode and decode signedData and
envelopedData content types that include v1 attribute certificates.  I don't
know of any operational use of v1 attribute certificates in signedData and
envelopedData content types.    

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

Date: Tue, 9 Oct 2001 16:55:40 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Encryption Cert OID
Sender: [email-masked]

Eric Norman <[email-masked]> writes:

>It's an OID that's used by Outlook Express to include the senders preferred
>encryption key among the bunch of certificates that are sent in a PKCS7
>signedData structure. The OID is 1.3.6.1.4.1.311.16.4 (seems to be in
>Microsoft's arc).  It is used as an authenticated attribute; the idea seems to
>be the same as SMIMEEncryptionKeyPreference (OID = 1.2.840.113549.1.9.16.2.11).
>The syntax is sligtly different; it "points to" the actual certificate with
>only IssuerAndSerialNumber; i.e. no CHOICE; no IMPLICIT tag.

It looks like you're using an old version of dumpasn1, this is already present
in the config:

-- Snip --

# This is just the normal issuerAndSerialNumber but with a MS-specific OID.
# Apparently it's used for CryptEncode/DecodeObject, whatever that is.
OID = 06 0A 2B 06 01 04 01 82 37 10 04
Comment = Microsoft attribute
Description = microsoftRecipientInfo (1 3 6 1 4 1 311 16 4)

-- Snip --

>There's an OID that seems like it should appear in
>http://www.imc.org/ietf-smime/other-smime-oids.asn

I think that's reserved specifically for S/MIME-related OIDs, not for any
random OID which a vendor might choose to invent.

Peter.

Date: Mon, 8 Oct 2001 21:04:36 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: SMIME list <[email-masked]>
Subject: Encryption Cert OID
Sender: [email-masked]

There's an OID that seems like it should appear in
http://www.imc.org/ietf-smime/other-smime-oids.asn

It's an OID that's used by Outlook Express to include the
senders preferred encryption key among the bunch of
certificates that are sent in a PKCS7 signedData structure.
The OID is 1.3.6.1.4.1.311.16.4 (seems to be in Microsoft's
arc).  It is used as an authenticated attribute; the idea
seems to be the same as SMIMEEncryptionKeyPreference
(OID = 1.2.840.113549.1.9.16.2.11).  The syntax is sligtly
different; it "points to" the actual certificate with only
IssuerAndSerialNumber; i.e. no CHOICE; no IMPLICIT tag.

I have no idea whether it's peculiar to Outlook Express
or also used in Outlook or any other details.

For gory details, here's a snippet from (a slightly
modified) Peter Gutmann's dumpasn1:

3829 30  201:g . . . . . . SEQUENCE {
3832 06    9:h . . . . . . . OBJECT IDENTIFIER '1 3 6 1 4 1 311 16 4'
3843 31  187:h . . . . . . . SET {
3846 30  184:i . . . . . . . . SEQUENCE {
3849 30  177:j . . . . . . . . . SEQUENCE {
3852 31   11:k . . . . . . . . . . SET {
3854 30    9:l . . . . . . . . . . . SEQUENCE {
3856 06    3:m . . . . . . . . . . . . OBJECT IDENTIFIER countryName (2 5 4 6)
3861 13    2:m . . . . . . . . . . . . PrintableString 'US'
            :l . . . . . . . . . . . }
            :k . . . . . . . . . . }
3865 31   18:k . . . . . . . . . . SET {
3867 30   16:l . . . . . . . . . . . SEQUENCE {
3869 06    3:m . . . . . . . . . . . . OBJECT IDENTIFIER
            :  . . . . . . . . . . . . . stateOrProvinceName (2 5 4 8)
3874 13    9:m . . . . . . . . . . . . PrintableString 'Wisconsin'
            :l . . . . . . . . . . . }
            :k . . . . . . . . . . }
3885 31   16:k . . . . . . . . . . SET {
3887 30   14:l . . . . . . . . . . . SEQUENCE {
3889 06    3:m . . . . . . . . . . . . OBJECT IDENTIFIER localityName (2 5 4 7)
3894 13    7:m . . . . . . . . . . . . PrintableString 'Madison'
            :l . . . . . . . . . . . }
            :k . . . . . . . . . . }
3903 31   32:k . . . . . . . . . . SET {
3905 30   30:l . . . . . . . . . . . SEQUENCE {
3907 06    3:m . . . . . . . . . . . . OBJECT IDENTIFIER
            :  . . . . . . . . . . . . . organizationName (2 5 4 10)
3912 13   23:m . . . . . . . . . . . . PrintableString 'University of Wisconsin'
            :l . . . . . . . . . . . }
            :k . . . . . . . . . . }
3937 31   43:k . . . . . . . . . . SET {
3939 30   41:l . . . . . . . . . . . SEQUENCE {
3941 06    3:m . . . . . . . . . . . . OBJECT IDENTIFIER
            :  . . . . . . . . . . . . . organizationalUnitName (2 5 4 11)
3946 13   34:m . . . . . . . . . . . . PrintableString 'Division of Information Technology'
            :l . . . . . . . . . . . }
            :k . . . . . . . . . . }
3982 31   45:k . . . . . . . . . . SET {
3984 30   43:l . . . . . . . . . . . SEQUENCE {
3986 06    3:m . . . . . . . . . . . . OBJECT IDENTIFIER commonName (2 5 4 3)
3991 13   36:m . . . . . . . . . . . . PrintableString 'UW Certificate Services -- 20000529A'
            :l . . . . . . . . . . . }
            :k . . . . . . . . . . }
            :j . . . . . . . . . }
4029 02    2:j . . . . . . . . . INTEGER 509
            :i . . . . . . . . }
            :h . . . . . . . }
            :g . . . . . . }

Eric Norman

        "I like to stand on the shoulders of the giants that
         have gone before me.  It is the only way I can see
         beyond the pile of dung that they left behind."

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "'Housley, Russ'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: WG Last Call: cmsalg
Date: Mon, 8 Oct 2001 17:37:48 -0700
Importance: Normal
Sender: [email-masked]

Paul,

No PKIX document should ever need to reference the v1 attribute ASN.1.
The problem is that the current attribute certificate draft in the PKIX
group uses the v2 attribute certificate ASN.1, while CMS originally
referenced the v1 attribute certificate ASN.1.  I don't think that
anybody actually implemented anything that uses the v1 attr
certificates, but Russ obviously feels that the ASN.1 should be
available in the event that anybody ever needs it under the same
availability as the rest of the ASN.1.  (This is not my position, since
I don't think anybody implemented and uses it, and it is now marked
obsolete, it could be omitted entirely and those people who need it can
search for it.)  Thus I don't think that anybody would ever end up
needing to refer to the ASN.1 unless they already are, and no PKIX
documents that I know of do so.

Jim

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]] 
> Sent: Monday, October 08, 2001 4:57 PM
> To: Housley, Russ; [email-masked]
> Cc: [email-masked]
> Subject: RE: WG Last Call: cmsalg
> 
> 
> At 5:29 PM -0400 10/8/01, Housley, Russ wrote:
> >I would certainly get the ASN.1 checked to make sure that it 
> >compiles before posting the updated draft in response to IETF Last 
> >Call.
> >
> >Alternative #3 is the only one that we both like.  I would like to 
> >hear from others.
> 
> OK, I'll chime in. Why is this the job of S/MIME? Shouldn't that 
> importing be being done in PKIX? Isn't it at least as valuable to 
> them as it is to us?
> 
> We could get into a silly state where some PKIX documents refer to an 
> S/MIME RFC because it has the v1 ASN.1 they want in it.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Mon, 8 Oct 2001 16:57:26 -0700
To: "Housley, Russ" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: WG Last Call: cmsalg
Cc: [email-masked]
Sender: [email-masked]

At 5:29 PM -0400 10/8/01, Housley, Russ wrote:
>I would certainly get the ASN.1 checked to make sure that it 
>compiles before posting the updated draft in response to IETF Last 
>Call.
>
>Alternative #3 is the only one that we both like.  I would like to 
>hear from others.

OK, I'll chime in. Why is this the job of S/MIME? Shouldn't that 
importing be being done in PKIX? Isn't it at least as valuable to 
them as it is to us?

We could get into a silly state where some PKIX documents refer to an 
S/MIME RFC because it has the v1 ASN.1 they want in it.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 08 Oct 2001 17:29:49 -0400
Subject: RE: WG Last Call: cmsalg
Sender: [email-masked]

Jim:

I would certainly get the ASN.1 checked to make sure that it compiles 
before posting the updated draft in response to IETF Last Call.

Alternative #3 is the only one that we both like.  I would like to hear 
from others.

Russ

At 11:56 AM 10/8/2001 -0700, Jim Schaad wrote:
>Russ,
>
>I would have a strong prefrence for either 2 or 3.  (Actually 3 would be
>nice since I would then have the ASN.1 for a v1 attribute certificate.)
>I disagree that this is a simple editorial change as we need to get
>compiles dones of the ASN.1 before it is finished and I don't want to
>try that in the 48 hour editors area.  In the past changes to the ASN.1
>modules have been deemed non-editorial changes.
>
>jim
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[email-masked]]
> > Sent: Monday, October 08, 2001 10:50 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: WG Last Call: cmsalg
> >
> >
> > Jim:
> >
> > As you pointed out in a message last week, the ASN.1 modules in both
> > rfc2630bis and cmsalg still include IMPORT statements from ITU-T
> > documents.  You recommended that these IMPORT statements
> > reference the
> > ASN.1 modules in the PKIX documents instead.  I did not make
> > this change
> > because there are no PKIX documents that include the definition of v1
> > attribute certificates.
> >
> > As I see it, we have three choices:
> > 1.  Do nothing.  Continue to IMPORT from ITU-T documents.
> > 2.  Use PKIX for everything except for v1 attribute
> > certificates; IMPORT v1
> > attribute certificates from ITU-T.
> > 3.  Use PKIX for everything except for v1 attribute
> > certificates; define v1
> > attribute certificates in the rfc2630bis appendix.
> >
> > I prefer either 1 or 3, so that all of the IMPORTS come from
> > the same class
> > of documents (RFC or ITU-T Recommendation).
> >
> > If we choose 1, then no further action is needed.
> >
> > If we choose 3, then I would like to make these editorial
> > changes when any
> > other IETF Last Call comments are handled.  I consider this
> > an editorial
> > change since it does not impact any implementation.  No bits
> > on the wire
> > are impacted.
> >
> > Russ
> >
> > At 07:43 PM 8/21/2001 -0700, Jim Schaad wrote:
> > >[JLS]  I would request that the PKIX module be used rather than the
> > >X.509 since that is more widely available.
> >

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: WG Last Call: cmsalg
Date: Mon, 8 Oct 2001 11:56:07 -0700
Importance: Normal
Sender: [email-masked]

Russ,

I would have a strong prefrence for either 2 or 3.  (Actually 3 would be
nice since I would then have the ASN.1 for a v1 attribute certificate.)
I disagree that this is a simple editorial change as we need to get
compiles dones of the ASN.1 before it is finished and I don't want to
try that in the 48 hour editors area.  In the past changes to the ASN.1
modules have been deemed non-editorial changes.

jim

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]] 
> Sent: Monday, October 08, 2001 10:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: WG Last Call: cmsalg
> 
> 
> Jim:
> 
> As you pointed out in a message last week, the ASN.1 modules in both 
> rfc2630bis and cmsalg still include IMPORT statements from ITU-T 
> documents.  You recommended that these IMPORT statements 
> reference the 
> ASN.1 modules in the PKIX documents instead.  I did not make 
> this change 
> because there are no PKIX documents that include the definition of v1 
> attribute certificates.
> 
> As I see it, we have three choices:
> 1.  Do nothing.  Continue to IMPORT from ITU-T documents.
> 2.  Use PKIX for everything except for v1 attribute 
> certificates; IMPORT v1 
> attribute certificates from ITU-T.
> 3.  Use PKIX for everything except for v1 attribute 
> certificates; define v1 
> attribute certificates in the rfc2630bis appendix.
> 
> I prefer either 1 or 3, so that all of the IMPORTS come from 
> the same class 
> of documents (RFC or ITU-T Recommendation).
> 
> If we choose 1, then no further action is needed.
> 
> If we choose 3, then I would like to make these editorial 
> changes when any 
> other IETF Last Call comments are handled.  I consider this 
> an editorial 
> change since it does not impact any implementation.  No bits 
> on the wire 
> are impacted.
> 
> Russ
> 
> At 07:43 PM 8/21/2001 -0700, Jim Schaad wrote:
> >[JLS]  I would request that the PKIX module be used rather than the
> >X.509 since that is more widely available.
> 

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 08 Oct 2001 13:50:06 -0400
Subject: RE: WG Last Call: cmsalg
Sender: [email-masked]

Jim:

As you pointed out in a message last week, the ASN.1 modules in both 
rfc2630bis and cmsalg still include IMPORT statements from ITU-T 
documents.  You recommended that these IMPORT statements reference the 
ASN.1 modules in the PKIX documents instead.  I did not make this change 
because there are no PKIX documents that include the definition of v1 
attribute certificates.

As I see it, we have three choices:
1.  Do nothing.  Continue to IMPORT from ITU-T documents.
2.  Use PKIX for everything except for v1 attribute certificates; IMPORT v1 
attribute certificates from ITU-T.
3.  Use PKIX for everything except for v1 attribute certificates; define v1 
attribute certificates in the rfc2630bis appendix.

I prefer either 1 or 3, so that all of the IMPORTS come from the same class 
of documents (RFC or ITU-T Recommendation).

If we choose 1, then no further action is needed.

If we choose 3, then I would like to make these editorial changes when any 
other IETF Last Call comments are handled.  I consider this an editorial 
change since it does not impact any implementation.  No bits on the wire 
are impacted.

Russ

At 07:43 PM 8/21/2001 -0700, Jim Schaad wrote:
>[JLS]  I would request that the PKIX module be used rather than the
>X.509 since that is more widely available.

Date: Mon, 8 Oct 2001 23:21:19 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: Questions on AuthenticatedData
Sender: [email-masked]

I wrote:

>Well, there are three major protocols which use HMAC, namely IPsec, SSL/TLS,
>and SSHv2 (aka "SSL done with SSH packet formats").  If macSize is the size of
>the generated MAC (128 bits for HMAC-MD5, 160 bits for HMAC-SHA) then SSL uses
>a key of size macSize, SSHv2 uses a key of size macSize, and I dunno about
>IPsec (the RFCs are silent on this, and I've never implemented it so I don't
>know what people use).

Before this ends up in a spec somewhere as "Anyone who doesn't use a <macSize>
key will be banished to van Diemens Land with only an ASN.1 dump for
companionship", does it actually matter what key size you use?  Since you can
wrap arbitrary-length keys, you could certainly include an implementation note
to say that the convention is to use keys of size <macSize>, but there's
nothing to prevent you from using keys of other lengths (the SSHv2 spec
actually requires the use of 128-bit keys, but I guess the <SSH-the-company>
implementation used 160-bit keys and everyone copied that).  In fact the only
reason that SSL/TLS and SSHv2 specify a size is because their key derivation
process performed after the key exchange part of the protocol handshake
generates a whole pile of keying material and it's necessary to fix where one
key stops and the next one starts.  This isn't an issue with CMS.

In fact if you're using a 128-bit AES key from (say) a KeyTransRecipientInfo to
MAC and encrypt you'd use 128 bits, if you're using a 3DES key it's your choice
between 160 and 192 bits, if all you've got is 64 bits you'd use that.  There's
no reason to restrict the choice, particularly since you can't control where
the keying material is coming from.

(Just looking at my own code, I use 128-bit keys for all the HMACs if the user
 doesn't specify otherwise, mostly because it's "the standard", but they can
 specify anything from 40 to INT_MAX or thereabouts if they want and it still
 works).

Peter.

Date: Mon, 8 Oct 2001 18:23:37 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Questions on AuthenticatedData
Sender: [email-masked]

"Jim Schaad" <[email-masked]> writes:

>Can you give a few places where this is the convention?  It seems counter to
>what would be intuitive looking at the Microsoft APIs.  This does not mean
>that you are not correct, I was just wondering.

Well, there are three major protocols which use HMAC, namely IPsec, SSL/TLS,
and SSHv2 (aka "SSL done with SSH packet formats").  If macSize is the size of
the generated MAC (128 bits for HMAC-MD5, 160 bits for HMAC-SHA) then SSL uses
a key of size macSize, SSHv2 uses a key of size macSize, and I dunno about
IPsec (the RFCs are silent on this, and I've never implemented it so I don't
know what people use).

Peter.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Questions on AuthenticatedData
Date: Sun, 7 Oct 2001 22:01:07 -0700
Importance: Normal
Sender: [email-masked]

Peter,

Can you give a few places where this is the convention?  It seems
counter to what would be intuitive looking at the Microsoft APIs.  This
does not mean that you are not correct, I was just wondering.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Sunday, October 07, 2001 6:45 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Questions on AuthenticatedData
> 
> 
> 
> "Jim Schaad" <[email-masked]> writes:
> 
> >1.  Should we specify a suggested size for the randomly 
> generated secret to be
> >used for HMAC-SHA1?  (The size for HMAC-3DES is fixed at the 
> size of a 3DES
> >key.)
> 
> The convention seems to be to use a 160-bit value (even if 
> the spec says that
> algorithms with variable-length keys use a 128-bit key and 
> you use that and
> then spend half a day trying to figure out why your MACs are 
> failing when all
> the other side tells you is "Bad MAC").
> 
> Peter.
> 

Date: Mon, 8 Oct 2001 14:45:15 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Questions on AuthenticatedData
Sender: [email-masked]

"Jim Schaad" <[email-masked]> writes:

>1.  Should we specify a suggested size for the randomly generated secret to be
>used for HMAC-SHA1?  (The size for HMAC-3DES is fixed at the size of a 3DES
>key.)

The convention seems to be to use a 160-bit value (even if the spec says that
algorithms with variable-length keys use a 128-bit key and you use that and
then spend half a day trying to figure out why your MACs are failing when all
the other side tells you is "Bad MAC").

Peter.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Subject: Questions on AuthenticatedData
Date: Sun, 7 Oct 2001 17:56:58 -0700
Importance: Normal
Sender: [email-masked]

I have just started an implemenation for AutenticatedData and have the
following questions:

1.  Should we specify a suggested size for the randomly generated secret
to be used for HMAC-SHA1?  (The size for HMAC-3DES is fixed at the size
of a 3DES key.)

2.  What key wrap algorithm should I use for wrapping the secret for an
HMAC-SHA1 secret?  I can see myself generating a 512 bit secret for the
MAC operation, now I need to wrap it in a 3DES, RC2 or AES key.  What is
the proper way of doing this?

3.  Does the answer for 2 imply that we want the lengths for 1 to be the
length of a defined content encrytion algorithm key?

Jim

From: "Blake Ramsdell" <[email-masked]>
To: "'James M Galvin '" <[email-masked]>, "'Housley, Russ '" <[email-masked]>
cc: "[email-masked]' '" <[email-masked]>
Subject: RE: multipart/signed clarifications
Date: Sat, 6 Oct 2001 09:13:11 -0700
Sender: [email-masked]

It's fine with me -- let's see if there are any other suggestions or
comments.

Blake

-----Original Message-----
From: James M Galvin
To: Housley, Russ; Blake Ramsdell
Cc: [email-masked]'
Sent: 10/6/2001 7:37 AM
Subject: Re: multipart/signed clarifications

I like #2.  As one of the authors of 1847 I've got a short list of
updates that could also be incorporated.

I'm volunteering to do this if you agree.

Jim

--
James M. Galvin <[email-masked]>

On Fri, 5 Oct 2001, Housley, Russ wrote:

    Date: Fri, 05 Oct 2001 16:51:09 -0400
    From: "Housley, Russ" <[email-masked]>
    To: Blake Ramsdell <[email-masked]>
    Cc: "[email-masked]'" <[email-masked]>
    Subject: Re: multipart/signed clarifications

    Blake:
    
    I like #1, as long as it includes some examples.
    
    Russ

    At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote:
    
    >Siegfried Schmitt mentioned in private email that using S/MIME with
detached
    >signatures (multipart/signed) could use some clarification, and I
agree.
    >There is always confusion about what exact data needs to be
digested in
    >order to create the signature.  However, this is a problem that
transcends
    >all multipart/signed implementations, and is not just limited to
S/MIME.
    >
    >Off the top of my head, I see some options:
    >
    >1. Create a new draft to supplement RFC1847 ("implementation notes
for
    >security multiparts")
    >
    >2. Reissue RFC1847 with modifications
    >
    >3. Stick some more verbiage in the new MSG draft, along with some
examples
    >
    >These are in order of my personal preference.  I know that there
are
    >implementors out there that can contribute to this, and I know that
OpenPGP
    >uses RFC1847 also, so a separate draft benefits everyone.
    >
    >Any comments?
    >
    >Blake
    >--
    >Blake C. Ramsdell, Tumbleweed Communications
    >Voice +1 425 376 0225 x103  Fax +1 425 376 0915

Date: Sat, 06 Oct 2001 10:37:07 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: multipart/signed clarifications
To: "Housley, Russ" <[email-masked]>, Blake Ramsdell <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

I like #2.  As one of the authors of 1847 I've got a short list of
updates that could also be incorporated.

I'm volunteering to do this if you agree.

Jim

--
James M. Galvin <[email-masked]>

On Fri, 5 Oct 2001, Housley, Russ wrote:

    Date: Fri, 05 Oct 2001 16:51:09 -0400
    From: "Housley, Russ" <[email-masked]>
    To: Blake Ramsdell <[email-masked]>
    Cc: "[email-masked]'" <[email-masked]>
    Subject: Re: multipart/signed clarifications

    Blake:
    
    I like #1, as long as it includes some examples.
    
    Russ

    At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote:
    
    >Siegfried Schmitt mentioned in private email that using S/MIME with detached
    >signatures (multipart/signed) could use some clarification, and I agree.
    >There is always confusion about what exact data needs to be digested in
    >order to create the signature.  However, this is a problem that transcends
    >all multipart/signed implementations, and is not just limited to S/MIME.
    >
    >Off the top of my head, I see some options:
    >
    >1. Create a new draft to supplement RFC1847 ("implementation notes for
    >security multiparts")
    >
    >2. Reissue RFC1847 with modifications
    >
    >3. Stick some more verbiage in the new MSG draft, along with some examples
    >
    >These are in order of my personal preference.  I know that there are
    >implementors out there that can contribute to this, and I know that OpenPGP
    >uses RFC1847 also, so a separate draft benefits everyone.
    >
    >Any comments?
    >
    >Blake
    >--
    >Blake C. Ramsdell, Tumbleweed Communications
    >Voice +1 425 376 0225 x103  Fax +1 425 376 0915

From: "Blake Ramsdell" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: multipart/signed clarifications
Date: Fri, 5 Oct 2001 15:43:04 -0700
Sender: [email-masked]

That's right -- I said "with some examples" for the MSG draft, but not for
any of the other options.  Yes, there would be examples in all cases to
illustrate the exact octets for digesting.

I am working on the MSG and CERT drafts right now, but I will do this
afterwards at least as a strawman for discussion.

Blake

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, October 05, 2001 1:51 PM
To: Blake Ramsdell
Cc: [email-masked]'
Subject: Re: multipart/signed clarifications

Blake:

I like #1, as long as it includes some examples.

Russ

At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote:

>Siegfried Schmitt mentioned in private email that using S/MIME with
detached
>signatures (multipart/signed) could use some clarification, and I agree.
>There is always confusion about what exact data needs to be digested in
>order to create the signature.  However, this is a problem that transcends
>all multipart/signed implementations, and is not just limited to S/MIME.
>
>Off the top of my head, I see some options:
>
>1. Create a new draft to supplement RFC1847 ("implementation notes for
>security multiparts")
>
>2. Reissue RFC1847 with modifications
>
>3. Stick some more verbiage in the new MSG draft, along with some examples
>
>These are in order of my personal preference.  I know that there are
>implementors out there that can contribute to this, and I know that OpenPGP
>uses RFC1847 also, so a separate draft benefits everyone.
>
>Any comments?
>
>Blake
>--
>Blake C. Ramsdell, Tumbleweed Communications
>Voice +1 425 376 0225 x103  Fax +1 425 376 0915

From: "Housley, Russ" <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 05 Oct 2001 16:51:09 -0400
Subject: Re: multipart/signed clarifications
Sender: [email-masked]

Blake:

I like #1, as long as it includes some examples.

Russ

At 11:48 AM 10/5/2001 -0700, Blake Ramsdell wrote:

>Siegfried Schmitt mentioned in private email that using S/MIME with detached
>signatures (multipart/signed) could use some clarification, and I agree.
>There is always confusion about what exact data needs to be digested in
>order to create the signature.  However, this is a problem that transcends
>all multipart/signed implementations, and is not just limited to S/MIME.
>
>Off the top of my head, I see some options:
>
>1. Create a new draft to supplement RFC1847 ("implementation notes for
>security multiparts")
>
>2. Reissue RFC1847 with modifications
>
>3. Stick some more verbiage in the new MSG draft, along with some examples
>
>These are in order of my personal preference.  I know that there are
>implementors out there that can contribute to this, and I know that OpenPGP
>uses RFC1847 also, so a separate draft benefits everyone.
>
>Any comments?
>
>Blake
>--
>Blake C. Ramsdell, Tumbleweed Communications
>Voice +1 425 376 0225 x103  Fax +1 425 376 0915

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: multipart/signed clarifications
Date: Fri, 5 Oct 2001 11:48:34 -0700
Sender: [email-masked]

Siegfried Schmitt mentioned in private email that using S/MIME with detached
signatures (multipart/signed) could use some clarification, and I agree.
There is always confusion about what exact data needs to be digested in
order to create the signature.  However, this is a problem that transcends
all multipart/signed implementations, and is not just limited to S/MIME.

Off the top of my head, I see some options:

1. Create a new draft to supplement RFC1847 ("implementation notes for
security multiparts")

2. Reissue RFC1847 with modifications

3. Stick some more verbiage in the new MSG draft, along with some examples

These are in order of my personal preference.  I know that there are
implementors out there that can contribute to this, and I know that OpenPGP
uses RFC1847 also, so a separate draft benefits everyone.

Any comments?

Blake
--
Blake C. Ramsdell, Tumbleweed Communications
Voice +1 425 376 0225 x103  Fax +1 425 376 0915

From: "Blake Ramsdell" <[email-masked]>
To: "'William Ottaway'" <[email-masked]>, [email-masked]
Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
Date: Thu, 4 Oct 2001 12:59:38 -0700
Sender: [email-masked]

Bill, thanks very much for doing this summary.

One thing that we were initially concerned about was that there was a
requirement for triple-wrapping and/or an empty signature layer (SignedData
with no SignerInfos).  If this requirement is gone, then I believe we can
simply make our document an "encrypting-only" profile for DOMSEC.

I propose that our current document continue to live, but with the following
changes:

1. Refer to DOMSEC in the relevant places in our draft

2. Remove the language about the email address in the certificate, and refer
to DOMSEC for this

3. Clarify that the additions that we have specified for handling
subdomains, etc. are in addition to DOMSEC (and thus the meat of this
profile)

The only impact for any existing implementations of our specification would
therefore be the recognition of the DOMSEC-specified email address
(domain-confidentiality-authority) as opposed to the smg_encryptor email
address that we originally specified in our draft.

Blake

-----Original Message-----
From: William Ottaway [mailto:[email-masked]]
Sent: Friday, September 21, 2001 6:42 AM
To: [email-masked]
Cc: Blake Ramsdell
Subject: DOMSEC and S/MIME Gateway Protocol comparison

At the S/MIME WG meeting in London I was tasked to provide a comparison
between DOMSEC and the S/MIME Gateway Protocol
(draft-ramsdell-enc-smime-gateway-00.txt) in order to start a discussion on
whether the gateway draft should be progressed and if so how would it relate
to DOMSEC.

DOMSEC Summary: -

1) Encryption/Decryption and signing.

2) Defines naming conventions.

3) Defines signature types.

4) Defines membership of a domain.

5) Defines rules for domain signature generation and verification.

6) States how domain encryption/decryption is achieved.

7) Defines domain signature application rules when sending to mail list
agents.

Gateway Summary: -

1) Encryption/Decryption only.

2) Uses same notation of domain "membership" as DOMSEC.

3) Introduces its own naming convention for the encrypting entities domain
certificate,    smg_encryptor@domain. DOMSEC defines
domain-confidentiality-authority@domain.

4) Introduces a mechanism for identifying multiple domains handled by the
gateway. They can be listed in a single certificate or in multiple
certificates.

5) Introduces a rule for deciding which recipient domain certificate must be
used.

6) Introduces a rule on how the gateway recognises that a message requires
encryption (encrypt if have a certificate for the recipients domain).

7) Introduces a rule on when the gateway should decrypt a message (when the
gateways public key has been used to encrypt)

My view: -

DOMSEC defines mechanisms for domain signing and encrypting with out
specifying mechanisms or rules that are deemed local to the installation. It
is hoped that domain signing and encryption implementations will be
compliant with DOMSEC. It is expected that individual installations will
provide extra local mechanisms and rules in support of DOMSEC, for example
how to decide on which certificate to use, how to decide on whether
encryption is required, how certificates are retrieved, whether a domain
signature is stripped off before forwarding to the local recipient, whether
encryption between the domain boundary and the local recipient is required,
etc.

The Gateway draft defines mechanisms that are already defined in DOMSEC,
such as encryption and naming notation. It also defines mechanisms that may
differ between implementations, such as domains that are handled by the
gateway may be listed in a single or multiple certificate and rules on which
recipient certificate to use when encrypting.

I propose that the Gateway draft should be a profile of DOMSEC. Therefore,
it should support encryption/decryption as specified in DOMSEC and the
DOMSEC naming convention. The Gateway draft would contain those features
local to this implementation such as points 4 - 7 in the gateway summary.

Bill
____________________________________________________
 William Ottaway BSc Hons CEng MBCS,
 Woodward B009,
 QinetiQ                      Tel: +44 (0) 1684 894079
 Malvern Technology Centre,   Fax: +44 (0) 1684 896660
 St. Andrews Road,            email: [email-masked]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.

Date: Fri, 05 Oct 2001 01:47:35 +0900
From: "Chung, KwonSung" <[email-masked]>
Organization: (C)BCQRE
To: [email-masked]
Subject: mime parser
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msBFEF04EFCA88A75D20F17558
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

Hello all,

Can I can a free source code for a mime message parser?

If you have or know about it, please let me know also.

Thank you.

--------------msBFEF04EFCA88A75D20F17558
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msBFEF04EFCA88A75D20F17558--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-smime-rfc2630bis-05.txt and  draft-ietf-smime-cmsalg-06.txt
Date: Thu, 4 Oct 2001 01:52:52 -0700
Importance: Normal
Sender: [email-masked]

The current version does not have the requested change by me to
reference the IETF ASN.1 modules for items such as certificate.  I
thought that you had agreed to do this.  Do I remember incorrectly or
did you change your mind?

Jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Wednesday, October 03, 2001 1:35 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: draft-ietf-smime-rfc2630bis-05.txt and 
> draft-ietf-smime-cmsalg-06.txt
> 
> 
> 
> Jeff & Marcus:
> 
> The S/MIME WG is finished with rfc2630bis-05 and cmsalg-06.  These 
> documents are ready for publication as standards-track RFCs 
> following IETF 
> Last Call and IESG approval.  The rfc2630bis-05 document 
> obsoletes RFC 2630.
> 
> 	Title		: Cryptographic Message Syntax
> 	Author(s)	: R. Housley
> 	Filename	: draft-ietf-smime-rfc2630bis-05.txt
> 	Pages		: 52
> 	Date		: 01-Oct-01
> 
> 	Title		: Cryptographic Message Syntax (CMS) Algorithms
> 	Author(s)	: R. Housley
> 	Filename	: draft-ietf-smime-cmsalg-06.txt
> 	Pages		: 23
> 	Date		: 01-Oct-01
> 
> Russ
> 

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 03 Oct 2001 16:34:39 -0400
Subject: draft-ietf-smime-rfc2630bis-05.txt and draft-ietf-smime-cmsalg-06.txt
Sender: [email-masked]

Jeff & Marcus:

The S/MIME WG is finished with rfc2630bis-05 and cmsalg-06.  These 
documents are ready for publication as standards-track RFCs following IETF 
Last Call and IESG approval.  The rfc2630bis-05 document obsoletes RFC 2630.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-05.txt
	Pages		: 52
	Date		: 01-Oct-01

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-06.txt
	Pages		: 23
	Date		: 01-Oct-01

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-sender-auth-00.txt
Date: Tue, 02 Oct 2001 07:04:33 -0400
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		: Sender Authentication and the Surreptitious Forwarding
                          Attack in CMS and S/MIME
	Author(s)	: D. Davis
	Filename	: draft-ietf-smime-sender-auth-00.txt
	Pages		: 
	Date		: 01-Oct-01
	
By default, a CMS signed-and-encrypted document or message authenticates
only the document's originator, and not the person who encrypted the
document.  This subtle limitation exposes CMS and S/MIME signed-and-encrypted data to 'surreptitious forwarding.'  Secure-messaging standards have treated surreptitious forwarding as an insoluble problem of user carelessness, and have long accepted the risk of this attack.  This document discusses easy cryptographic remedies for this attack, suitable for incorporation into the CMS and S/MIME specifications.  This document is an abridgement of [U2001].

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-sender-auth-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-sender-auth-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-sender-auth-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-06.txt
Date: Tue, 02 Oct 2001 07:04:26 -0400
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		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-06.txt
	Pages		: 23
	Date		: 01-Oct-01
	
This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS].  CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary messages.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cmsalg-06.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-05.txt
Date: Tue, 02 Oct 2001 07:04:21 -0400
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		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-05.txt
	Pages		: 52
	Date		: 01-Oct-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

--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-rfc2630bis-05.txt

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

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

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Pawling, John'" <[email-masked]>, "'Housley, Russ'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Tue, 2 Oct 2001 01:32:47 -0700
Importance: Normal
Sender: [email-masked]

John,

I re-examined this and I agree that you are correct and that the
language in the updated draft is correct.

Interestingly, I now understand the reason that all new content infos
are required to NOT start with a CHOICE.  Specifically the tag
representing the choice is not covered by the signature and thus is open
to changing under the PKCS#7 rules (but not under the updated CMS
rules).

I don't know that there are any advantages to removing the requirement
from the updated CMS draft, but it is certainly no longer needed as the
byte is now covered by the signature (and is one less odd ball statement
to have around).

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pawling, John
> Sent: Wednesday, September 19, 2001 1:44 PM
> To: [email-masked]'; 'Housley, Russ'
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
> 
> 
> 
> Jim,
> 
> > However, if an
> >     RFC 2634 signed receipt is encapsulated in the PKCS #7 
> signedData
> >     type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
> >     SignedData contentInfo content ANY field (a SEQUENCE, 
> not an OCTET
> >     STRING).  Therefore, the message digest is computed 
> using only the
> >     value octets of the Receipt SEQUENCE encoding.
> 
> [Jim wrote: I have a minor issue with the last sentence.  The 
> digest must
> include
> the type and length bytes of the SEQUENCE and I don't believe 
> that this
> is correctly  stated in the text.  Suggest: "Therefore, the message
> digest is computed using the entirety of the Receipt SEQUENCE 
> encoding."]
> 
> I agree that when an RFC 2634 [ESS] signed receipt is 
> encapsulated in the
> CMS signedData type, then the message digest is computed 
> using the entire
> Receipt SEQUENCE encoding (as specified in RFC 2634 and RFC 
> 2630).  However,
> when a signed receipt is encapsulated in the PKCS #7 
> signedData type, then
> RFC 2315 (PKCS #7), Section 9.3 (see below) specifies that the message
> digest is computed using only the value octets (not the 
> identifier octets or
> the length octets) of the "content being signed" (i.e. 
> Receipt SEQUENCE
> encoding).  
> 
> When we performed signed receipt interoperability testing 
> between the S/MIME
> Freeware Library (SFL) and Microsoft, the Microsoft implementation was
> initially encapsulating the signed receipt in a PKCS #7 
> signedData type.
> When creating a PKCS #7 signed receipt, the Microsoft 
> implementation encoded
> the Receipt SEQUENCE in the SignedData contentInfo content 
> ANY field (a
> SEQUENCE, not an OCTET STRING) and calculated the message 
> digest using only
> the value octets of the Receipt SEQUENCE encoding.  Once we 
> modified the SFL
> to accept this format, then we were able to decode and verify 
> the Microsoft
> PKCS #7 signed receipt.  Please note that Microsoft later generated a
> >>CMS<< signed receipt that we were able to decode and verify 
> using the SFL
> without any special modifications.
> 
> RFC 2315 (PKCS #7), Section 9.3:
> 
>   "9.3 Message-digesting process
> 
>    The message-digesting process computes a message digest on 
> either the
>    content being signed or the content together with the signer's
>    authenticated attributes. In either case, the initial input to the
>    message-digesting process is the "value" of the content 
> being signed.
>    Specifically, the initial input is the contents octets of the DER
>    encoding of the content field of the ContentInfo value to which the
>    signing process is applied. Only the contents octets of the DER
>    encoding of that field are digested, not the identifier 
> octets or the
>    length octets."
> 
> ===========================================
> John Pawling, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
> 

From: RFC Editor <[email-masked]>
Date: Mon, 1 Oct 2001 13:12:58 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: authors 48 hours: RFC 3183 <draft-ietf-smime-domsec-09.txt> NOW AVAILABLE
Cc: [email-masked], [email-masked]
Sender: [email-masked]

****IMPORTANT*****

Updated 2001/10/01

RFC AUTHOR(S):
--------------

This is your LAST CHANCE to make changes to your RFC to be:
draft-ietf-smime-domsec-09.txt, once the document is published we
*WILL NOT* make any changes.  

Please check your document at

	ftp://ftp.rfc-editor.org/in-notes/authors/rfc2183.txt	

You have 48 hours (2 WORK days) to look over your document for any
last minute editorial nits, *especially check your code.*  If the main
editor of your document is out of town, or if you are going out of
town you may request an extension.  Extensions are granted at the
prerogative of the RFC Editor.

** Please send us a list of suitable keywords for this document, over
and above those which appear in the title.  

	Frequently INCORRECT information includes

	- Contact Information
	- References (are they up to date)
	- Section Numbers
	  (especially if you originally put the copyright somewhere 
	  other than the VERY end of the document, or if you numbered
	  the "Status of the Memo" field)

Please send us the changes, *DO NOT* send a new document with the
changes made.  (If we think that the changes might be more than
editorial we will contact the AD or the IESG to confirm that the
changes do not require review.)

Send us the changes in THIS format.

	1)*** SECTION #'s***  [i.e. Section 5, 2nd paragraph] 
	2) the text you want changed, 
	3) the new correct text and 
	4) if the changes are spacing or indentation than please note 
	   that.

FOR EXAMPLE:

	Section 5.6, 3rd paragraph

 	OLD: 
		The quick brown fox jumped over the lazy dog.

	NEW: 
		The quick brown dog jumps over the lazy fox.
				^^^     ^               ^^^

If you have a whole paragraph to replace you do not need to use
the arrow to point out the differences

	INTRODUCTION, 2nd paragraph

	Replace OLD:

		alsdfja;sldjf;lajsd;fljas;dlfj;

	With NEW:
		
		nv;alkjd;lsf;aoisj;ltjka;sldkjf	

Spacing or indentation problems...

	Section 10, 1st paragraph (remove spaces between bit 
	and of, add space after butter)

	OLD:

	Better botter bought a bit
		of bitter butterMary mary quite contrary

	NEW:

	Better botter bought a bit of bitter butter

	Mary mary quite contrary

If we do not hear from you within 48 hours of this email, the document
will be published to the community at large AS IS.  

Thanks for your cooperation,

-RFC Editor

====================================================================

A new Request for Comments is now available from ftp.isi.edu.  As
the contact for a primary RFC library, you are responsible for
retrieving this RFC from ISI and installing it in your RFC library.
The official RFC announcement will be sent to the public distribution
list in one working day from this posting.

        RFC 3183

        Title:	    Domain Security Services using S/MIME
        Author(s):  T. Dean, W. Ottaway
        Status:     Experimental
	Date:       October 2001
        Mailbox:    [email-masked],
                    [email-masked] 
        Pages:      24
        Characters: 57330
        SeeAlso/Updates/Obsoletes:    None

        I-D Tag:    draft-ietf-smime-domsec-09.txt

	pathname:   ftp://ftp.rfc-editor.org/in-notes/rfc3183.txt

======================================================================

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Reuse of CMS Content Encryption Keys to Proposed Standard
Date: Mon, 01 Oct 2001 06:58:54 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Reuse of CMS Content
Encryption Keys' <draft-ietf-smime-rcek-04.txt> as a Proposed
Standard.  This document is the product of the S/MIME Mail Security
Working Group.  The IESG contact persons are Jeffrey Schiller and
Marcus Leech.

Technical Summary
 
  SMIME's Cryptographic Message Syntax (CMS) provides a way to use
  public key cryptography to encrypt a symmetric key which in turn is
  used to encrypt the content of the message.

  There are applications where two parties may need to exchange
  multiple messages and wish to avoid the overhead of the public key
  operation (public key cryptography is much more computationally
  expensive then symmetric algorithms).

  This document defines a secure way of labeling the symmetric key
  (called the Content Encryption Key or CEK) in a message such that it
  may be used as a Key Encrypting Key (KEK) for a later message.

  This technique is not advisable for just any application and the
  document explains where it makes sense and where it doesn't.

Working Group Summary

  The S/MIME Working Group came to consensus on this document.

Protocol Quality

  This protocol was reviewed for the IESG by Jeffrey I. Schiller.