S/MIME in VC++

["Kiefer, Sascha" <[e-mail]>]

Hi,

i hope somebody can explain what my problem is.
I'm trying to read and write s/mime attachements on mails.
I already manged to crypt, sign, decrypt and verify files using the platform
SDK functions on MSVC++.
But reading in a s/mime attachment using my functions to decrypt files won't
work!
Does anybody know how i have to fight throught my problem?
Thanks.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBS9Uoq22433 for ietf-smime-bks; Fri, 28 Dec 2001 01:30:50 -0800 (PST)
Received: from diagate.dialogika.de (diagate.dialogika.de [192.109.199.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBS9Ul222429 for <[e-mail]>; Fri, 28 Dec 2001 01:30:47 -0800 (PST)
Received: from virus.dialogika.de (virus.dialogika.de [192.109.199.10]) by diagate.dialogika.de (8.9.3/0.8.15) with SMTP id KAA17814 for <[e-mail]>; Fri, 28 Dec 2001 10:35:04 +0100
Received: from 192.109.199.2 by virus.dialogika.de (InterScan E-Mail VirusWall NT); Fri, 28 Dec 2001 10:32:43 +0100 (W. Europe Standard Time)
Received: from diagate.dialogika.de ([192.109.199.2]) by diagate.dialogika.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id fBS9Z4L17810 for <[e-mail]>; Fri, 28 Dec 2001 10:35:04 +0100
X-Authentication-Warning: diagate.dialogika.de: Host [192.109.199.2] claimed to be diagate.dialogika.de
Received: from yellow.dialogika.de (yellow.dialogika.de [192.54.36.15]) by diagate.dialogika.de (8.9.3/0.8.15) with ESMTP id KAA17806 for <[e-mail]>; Fri, 28 Dec 2001 10:35:03 +0100
Received: by yellow.dialogika.de with Internet Mail Service (5.5.2650.21) id <XTGM5Y6X>; Fri, 28 Dec 2001 10:30:47 +0100
Message-ID: <[e-mail]>
From: "Kiefer, Sascha" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: S/MIME in VC++
Date: Fri, 28 Dec 2001 10:30:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

i hope somebody can explain what my problem is.
I'm trying to read and write s/mime attachements on mails.
I already manged to crypt, sign, decrypt and verify files using the platform
SDK functions on MSVC++.
But reading in a s/mime attachment using my functions to decrypt files won't
work!
Does anybody know how i have to fight throught my problem?
Thanks.


Received: by above.proper.com (8.11.6/8.11.3) id fBRJdKB09886 for ietf-smime-bks; Thu, 27 Dec 2001 11:39:20 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBRJdH209876 for <[e-mail]>; Thu, 27 Dec 2001 11:39:17 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Dec 2001 19:39:03 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA19737 for <[e-mail]>; Thu, 27 Dec 2001 14:39:19 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBRJdIK03774 for <[e-mail]>; Thu, 27 Dec 2001 14:39:18 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NB4N3>; Thu, 27 Dec 2001 14:39:17 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NB4NL; Thu, 27 Dec 2001 14:39:13 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Thu, 27 Dec 2001 14:34:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Ned.  This approach makes sense, but this is not what I thought you 
meant by your first posting.

Russ


At 09:19 AM 12/27/2001 -0800, [e-mail] wrote:
> > It seems that message/rfc822 is used to encapsulate an entire message.
In
> > this case, we want to repeat a subset of the RFC 822 header lines from
the
> > current message, and we never want to duplicate the body.
>
>I think this is the wrong way to go about it. If you want to protect an
>entire message including its outermost headers, simply place the entire
>message inside your protective envelope using the message/rfc822 construct.
>Then strip the outer, unprotected header to its barest essentials.
>
>The process is then reversed by the receiver.
>
>This approach uses nothing but existing media types and can leverage
existing
>support for message/partial and message/rfc822. It doesn't require that 
>you add
>additional fields to your structures, with all the attendant deployment
>problems that will cause.
>
> > The required support for message/rfc822 is attractive, but I am not sure
> > that is has the correct semantics.  Can you explain your idea further?
>
>See above. At most what's needed here is an indicator in the protected
content
>that it is to be merged with the outer message header on receipt. That
could
>easily be done with either a message-context or a content-disposition field
in
>the protected content.
>
>                                 Ned




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: by above.proper.com (8.11.6/8.11.3) id fBRHPlI04641 for ietf-smime-bks; Thu, 27 Dec 2001 09:25:47 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRHPj204637 for <[e-mail]>; Thu, 27 Dec 2001 09:25:46 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 27 Dec 2001 09:25:46 -0800 (PST)
Date: Thu, 27 Dec 2001 09:19:14 -0800 (PST)
From: [e-mail]
Subject: Re: The subject line leakage problem
In-reply-to: "Your message dated Thu, 27 Dec 2001 10:38:09 -0500" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> It seems that message/rfc822 is used to encapsulate an entire message.  In
> this case, we want to repeat a subset of the RFC 822 header lines from the
> current message, and we never want to duplicate the body.

I think this is the wrong way to go about it. If you want to protect an
entire message including its outermost headers, simply place the entire
message inside your protective envelope using the message/rfc822 construct.
Then strip the outer, unprotected header to its barest essentials.

The process is then reversed by the receiver.

This approach uses nothing but existing media types and can leverage existing
support for message/partial and message/rfc822. It doesn't require that you add
additional fields to your structures, with all the attendant deployment
problems that will cause.

> The required support for message/rfc822 is attractive, but I am not sure
> that is has the correct semantics.  Can you explain your idea further?

See above. At most what's needed here is an indicator in the protected content
that it is to be merged with the outer message header on receipt. That could
easily be done with either a message-context or a content-disposition field in
the protected content.

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRFxUe28469 for ietf-smime-bks; Thu, 27 Dec 2001 07:59:30 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBRFxL228429 for <[e-mail]>; Thu, 27 Dec 2001 07:59:21 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Dec 2001 15:59:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA07668 for <[e-mail]>; Thu, 27 Dec 2001 10:59:22 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBRFxKs20232 for <[e-mail]>; Thu, 27 Dec 2001 10:59:20 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NBR0K>; Thu, 27 Dec 2001 10:59:19 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.34]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NBR0C; Thu, 27 Dec 2001 10:59:13 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Thu, 27 Dec 2001 10:20:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul:

I was trying to be a good reporter.  I was not trying to put any spin 
(positive or negative) on the comments.  I will try to answer your
questions.

>>First, he is pleased to see the working group addressing the subject line
>>issue.  While this issue was not part of his initial concerns, he agrees
>>that it deserves a solution.
>
>Non-To: headers are of concern, but they are a completely different beast 
>than To: headers with respect to Don's draft.

Don acknowledges the difference.  He is glad that we are discussing a 
solution that addresses the issues that he raised as well as issues raised 
by others.

>>Second, he would like to see the working group mandate the inclusion of
the
>>TO, CC, and FROM lines whenever encryption and signature are used
>>together.
>
>Why only those headers? Other headers are also important. Date: comes to
mind.

These are the ones that Don and I discussed on the phone.  Further, Don 
acknowledges the issues with BCC and mail lists.

I do not think that DATE is particularly important if the signing-time 
attribute is used.

>>   As he explained in is I-D, he does not believe that many users
>>are able to understand the interaction between signing, encrypting, or
both
>>(in either order).
>
>True.
>
>>Third, he would like to see the TO, CC, and FROM lines automatically
>>processed by the receiving mail agent software.  While he acknowledges the
>>issues associated with BCC, mail lists, and so on, he firmly believes that
>>the people writing the software understand the situation much better than
>>mass market e-mail users.
>
>True.
>
>>Fourth, he would like to see the working group mandate the inclusion of
the
>>TO, CC, and FROM lines whenever the sending agent or the receiving agent
>>represents a human.  In other words, computer-to-computer communications
>>may not need these to be protected.
>
>And we determine that how?

I will offer my interpretation of his comments.  When someone builds a 
piece of software, they have a target market for that software.  When mail 
agent software is intended for computer-to-computer communications, he not 
too concerned because, as stated above, Don has more faith in programmers 
than mass market mail system users.

 From a specification point of view, it would be much easier to require the 
inclusion of these fields all of time.

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: by above.proper.com (8.11.6/8.11.3) id fBRFxPq28447 for ietf-smime-bks; Thu, 27 Dec 2001 07:59:25 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBRFxL228428 for <[e-mail]>; Thu, 27 Dec 2001 07:59:21 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Dec 2001 15:59:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA07666 for <[e-mail]>; Thu, 27 Dec 2001 10:59:22 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBRFxKO20230 for <[e-mail]>; Thu, 27 Dec 2001 10:59:20 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NBR02>; Thu, 27 Dec 2001 10:59:19 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.34]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NBR0D; Thu, 27 Dec 2001 10:59:14 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Thu, 27 Dec 2001 10:38:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned:

It seems that message/rfc822 is used to encapsulate an entire message.  In 
this case, we want to repeat a subset of the RFC 822 header lines from the 
current message, and we never want to duplicate the body.

The required support for message/rfc822 is attractive, but I am not sure 
that is has the correct semantics.  Can you explain your idea further?

Russ


At 06:39 PM 12/21/2001 -0800, you wrote:


>>This is getting much more complicated than it needs to be, and is
>>likely to break interoperability with non-enhanced clients.
>
>>The simplest thing to do is to say:
>>- Senders should put the minimum that they want in the unprotected headers
>>- Senders include as much as they want protected in a
>>text/rfc822-header part at the beginning of a multipart/mixed message
>>- Enhanced clients should display the message with the headers from
>>the text/rfc822-header part moved to where the user thinks he/she
>>sees the headers. In the case of headers that are in both in the 822
>>message and in the text/rfc822-header body part, the latter wins
>>(because it is protected)
>
>Even simpler than this is to use message/rfc822. It has the advantage that
>conformant MUAs are supposed to handle it. There is no such requirement for
>text/rfc822-header.
>
>>- The moved-up headers may cause side-effects that the MUA should act
>>on. For example, if the Cc: in the 822 headers is "[e-mail]"
>>but the Cc: in the protected headers is "[e-mail]", the "reply
>>to all" action should include amy but not include bill.
>
>The rules for header merging from message/partial can probably be applied
>here.
>
>                                 Ned




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRD7G816218 for ietf-smime-bks; Thu, 27 Dec 2001 05:07:16 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRD7E216214 for <[e-mail]>; Thu, 27 Dec 2001 05:07:14 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id fBRD3us04255; Thu, 27 Dec 2001 05:03:56 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2YDCF5B>; Thu, 27 Dec 2001 05:07:57 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: RE: The subject line leakage problem
Date: Thu, 27 Dec 2001 05:07:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18ED7.793ABD10"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C18ED7.793ABD10
Content-Type: text/plain;
	charset="iso-8859-1"

All,

	I for one would be all in favor of putting in place a
fully spec'd kosher solution here. 

	However the issue of introduction and backwards compatibility
need to be carefully considered. We don't want to have people not
implement the full fix because they are waiting for others to deploy.

	I would like to keep the hack on the table as an interim
patch for the time being. Certainly the sooner we stop leaking
subject lines the better

	I don't consider the security of any other headers to be 
particularly serious. Routing info is disclosed as a matter of course 
and the existence of mailling lists and byzantine forwarding makes
the intended recipient issue impossible to resolve.

		Phill


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


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, December 18, 2001 9:42 AM
> To: Hallam-Baker, Phillip
> Cc: [e-mail]
> Subject: Re: The subject line leakage problem
> 
> 
> Phil:
> 
> Thanks for raising this issue.
> 
> After the intended-recipients discussion, it was clear to me 
> that several 
> RFC 821 header lines needed various forms of protection.  The 
> level of 
> automated checking is different for each of them.  Some need 
> confidentiality, and others do not (and cannot without 
> disrupting the mail 
> delivery).
> 
> I would like to steer this discussion toward a signed 
> attribute (a CHOICE 
> of IA5String and UTF8String (for international characters 
> that are coming 
> soon)).  The attribute would contain a subset of the header lines.
> 
> My initial cut at the header lines that ought to be included 
> are FROM, TO, 
> CC, SUBJECT, and DATE.  So, for Phil's message that started 
> this thread, 
> the attribute would contain:
> 
>      From: "Hallam-Baker, Phillip" <[e-mail]>
>      To:
>      Cc: [e-mail]
>      Subject: The subject line leakage problem
>      Date: Mon, 17 Dec 2001 10:34:39 -0800
> 
> I think that the content-hints attribute defined in RFC 2634 
> should be used 
> to carry the real subject line when the RFC 821 header 
> carries a masked 
> subject line.
> 
> Russ
> 
> 
> At 10:34 AM 12/17/2001 -0800, Hallam-Baker, Phillip wrote:
> >All,
> >
> >         One of the ongoing problems with people using PGP 
> is that people put
> >confidential information in the mail subject lines, eg:
> >
> >Subject: Proposed purchase of Excite@Home
> >Subject: Your STD test results
> >Subject: Planned head count reduction
> >
> >         etc.
> >
> >So over the years there have been plenty of fixes involving 
> CMS encrypted
> >attributes etc. which gets into the rat hole of what other 
> headers to add
> >in.
> >
> >So instead of that how about the following fix:
> >
> >1) A Best Current Practice Draft that says
> >2) Clients SHOULD offer users the option of replacing the 
> subject line on
> >confidential messages and carrying the subject as the first 
> line in the body
> >of the message.
> >
> >
> >So the above message would become
> >
> >Subject: Confidential
> >Subject: Confidential
> >Subject: Confidential
> >
> >And when opened we get something like:
> >
> >Subject: Confidential
> >
> >Subject: Proposed purchase of Excite@Home
> >
> >Alice,
> >         Yadda Yadda Yadda ....
> >
> >
> >         So, no need for any modification of existing specs, complete
> >backwards interop and the bug in the spec gets fixed.
> >
> >                 Phill
> >
> >Phillip Hallam-Baker FBCS C.Eng.
> >Principal Scientist
> >VeriSign Inc.
> >[e-mail]
> >781 245 6996 x227
> >
> >
> >
> 


------_=_NextPart_000_01C18ED7.793ABD10
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:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C18ED7.793ABD10--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBR5EHI06722 for ietf-smime-bks; Wed, 26 Dec 2001 21:14:17 -0800 (PST)
Received: from Bonatti-Gateway (cp2168599-a.mtgmry1.md.home.com [65.14.161.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBR5EG206718 for <[e-mail]>; Wed, 26 Dec 2001 21:14:16 -0800 (PST)
Received: from [127.0.0.1] by Bonatti-Gateway (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 27 Dec 2001 00:14:20 -0500
From: "Bonatti, Chris" <[e-mail]>
To: "IETF SMIME WG" <[e-mail]>
Subject: MIXER Impact on CMS-X400
Date: Thu, 27 Dec 2001 00:14:18 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fBR5EH206719
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

   As Russ reported at the meeting in Salt Lake, the IESG has expressed some concern that we address the relationship (or lack thereof) between the CMS-X400 specs and the MIXER standards.  The MIXER document (RFC 2156) and the BODYMAP document (RFC 2157) specify how to perform gateway translations between SMTP/MIME and X.400 envelope and P22 content.  The IESG's concern seemed to arise from the fact that the X400WRAP and X400TRANSPORT drafts dealt with mixtures of X.400 and MIME objects, but did not give any consideration to the only other RFCs that did so.  This seems to be a reasonable concern.

   Fortunately, the possible interaction between our drafts and the MIXER standards is very limited.  Obviously, in the case where you're dealing in signed or encrypted content, the application of gateway translations cannot affect the content without first removing the CMS wrappers.  In the case of the X400WRAP draft, any translation is simply out of scope.  In the case of the X400TRANSPORT draft, gateway translation of the envelope only is fully possible without interfering with the security services.  However, the translations (and MIXER) remain orthoganal to our work.

   In this light, I have been considering some additional text to make this situation clearer in both documents.  As a result, I propose the following amendments to the document draft-ietf-smime-x400transport-04:

- Append a new 2nd para to "1. Introduction"

	This document describes a mechanism for using CMS objects in 
	an otherwise native X.400 environment.  It describes an 
	environment that deliberately uses a mix of technologies, but 
	does not describe any gateway operations, per se.  It is 
	possible to combine the provisions of this document with 
	gateway operations, such as specified in [MIXER].  However,
	translation must be limited to the envelope fields only since
	modification of the CMS-protected content would invalidate 
	S/MIME security services.

- Add to the "A. References" section:

	[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced
	Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 
	January 1998.


Also, I would propose the following amendments to the document draft-ietf-smime-x400wrap-04:

- Append a new 5th para to "1.1 Specification Overview"

	This document describes use of security services for X.400 content 
	that will not interact well with gateway services, such as described 
	in [MIXER].  Translations limited to envelope processing may be 
	viable in the context of this document.  Body translations, such 
	as described in [BODYMAP], cannot be performed without removing 
	S/MIME security services.  Translation after removal of the CMS 
	security measures described herein is beyond the scope of this 
	document.

- Add to the "A. References" section:

	[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced
	Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 
	January 1998.

	[BODYMAP]	Alvestrand, H., Editor, "Mapping between X.400 and 
	RFC-822/MIME Message Bodies", RFC 2157, January 1998.


   I look forward to any feedback on this approach, or on my specific proposed text.  

Best holiday wishes to all,
Chris B.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBM2srW12426 for ietf-smime-bks; Fri, 21 Dec 2001 18:54:53 -0800 (PST)
Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBM2sp212422 for <[e-mail]>; Fri, 21 Dec 2001 18:54:51 -0800 (PST)
Received: from sdn-ar-001njhackp205.dialsprint.net ([168.191.60.117] helo=[209.246.97.52]) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16HcJI-0007MB-00; Fri, 21 Dec 2001 18:54:53 -0800
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510100db84973e29d50@[209.246.97.52]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Fri, 21 Dec 2001 21:14:13 -0500
To: "Housley, Russ" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: The subject line leakage problem
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:44 PM -0500 12/21/01, Housley, Russ wrote:
>First, he is pleased to see the working group addressing the subject line
>issue.  While this issue was not part of his initial concerns, he agrees
>that it deserves a solution.

Non-To: headers are of concern, but they are a completely different 
beast than To: headers with respect to Don's draft.

>Second, he would like to see the working group mandate the inclusion of the
>TO, CC, and FROM lines whenever encryption and signature are used
>together.

Why only those headers? Other headers are also important. Date: comes to mind.

>   As he explained in is I-D, he does not believe that many users
>are able to understand the interaction between signing, encrypting, or both
>(in either order).

True.

>Third, he would like to see the TO, CC, and FROM lines automatically
>processed by the receiving mail agent software.  While he acknowledges the
>issues associated with BCC, mail lists, and so on, he firmly believes that
>the people writing the software understand the situation much better than
>mass market e-mail users.

True.

>Fourth, he would like to see the working group mandate the inclusion of the
>TO, CC, and FROM lines whenever the sending agent or the receiving agent
>represents a human.  In other words, computer-to-computer communications
>may not need these to be protected.

And we determine that how?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id fBM2eXZ12253 for ietf-smime-bks; Fri, 21 Dec 2001 18:40:33 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBM2eW212247; Fri, 21 Dec 2001 18:40:32 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 21 Dec 2001 18:40:20 -0800 (PST)
Date: Fri, 21 Dec 2001 18:39:06 -0800 (PST)
From: [e-mail]
Subject: Re: The subject line leakage problem
In-reply-to: "Your message dated Wed, 19 Dec 2001 11:59:28 -0500" <p05101003b846768bf45f@[168.191.59.169]>
To: Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> This is getting much more complicated than it needs to be, and is
> likely to break interoperability with non-enhanced clients.

> The simplest thing to do is to say:
> - Senders should put the minimum that they want in the unprotected headers
> - Senders include as much as they want protected in a
> text/rfc822-header part at the beginning of a multipart/mixed message
> - Enhanced clients should display the message with the headers from
> the text/rfc822-header part moved to where the user thinks he/she
> sees the headers. In the case of headers that are in both in the 822
> message and in the text/rfc822-header body part, the latter wins
> (because it is protected)

Even simpler than this is to use message/rfc822. It has the advantage that
conformant MUAs are supposed to handle it. There is no such requirement for
text/rfc822-header.

> - The moved-up headers may cause side-effects that the MUA should act
> on. For example, if the Cc: in the 822 headers is "[e-mail]"
> but the Cc: in the protected headers is "[e-mail]", the "reply
> to all" action should include amy but not include bill.

The rules for header merging from message/partial can probably be applied
here.

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLKFjb22580 for ietf-smime-bks; Fri, 21 Dec 2001 12:15:45 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLKFi222574 for <[e-mail]>; Fri, 21 Dec 2001 12:15:44 -0800 (PST)
Received: from revelation ([12.230.197.121]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011221201531.LZMQ6450.rwcrmhc52.attbi.com@revelation>; Fri, 21 Dec 2001 20:15:31 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Encoding of enhanced content types in CMS
Date: Fri, 21 Dec 2001 12:15:09 -0800
Message-ID: <004101c18a5c$30542610$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There is no need to specify the encoding rules for this.  The content is
contained within an OCTET wrapping, and all of the bytes are encoded
(unlike PKCS#7 where the first type and length bytes are not).  Once you
have removed the octet wrapping, you can decode using what ever rules
you have.  Generally people will either DER or BER encode the embedded
content so that attempting to decode as BER will work (DER is a subset
of BER).

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Friday, December 21, 2001 10:36 AM
> To: [e-mail]
> Subject: Encoding of enhanced content types in CMS
> 
> 
> 
> A major difference I find between CMS and PKCS#7 (from which CMS is
> derived) is the fact that in PKCS#7 it is well defined how to encode
> enhanced types to be used as content for another enhanced type.
> 
> " Content types in the enhanced class contain content of some type
> (possibly encrypted), and other cryptographic enhancements. 
> For example,
> enveloped-data content can contain (encrypted) signed-data 
> content, which
> can contain data content. "
> 
> Specifically, in Section "7.General Sintax", Note 2:
> 
> " When a ContentInfo value is the inner content of signed-data,
> signed-and-enveloped-data, or digested-data content, a message-digest
> algorithm is applied to the contents octets of the DER encoding of the
> content field. When a ContentInfo value is the inner content of
> enveloped-data or signed-and-enveloped-data content, a 
> content-encryption
> algorithm is applied to the contents octets of a definite-length BER
> encoding of the content field. "
> 
> On the other hand. CMS does not define any encoding rules at 
> all. The new
> draft of the CMS points out the question of compatibility with PKCS#7
> (section 5.2.1) with the inclusion or not of the tag and 
> lenght octets in
> the encoding of a SEQUENCE in the encapContentInfo eContent 
> field, but it
> eludes again the matter of which encoding rules should be used in CMS.
> Does not it implies that incompatibilities may arise between different
> implementations of CMS when the content processed (digested 
> or encrypted)
> was other than Data? Suppose I receive a CMS EnvelopedData 
> type, and the
> encryptedContentInfo contentType is SignedData. After the decryption
> process, how am I supposed to decode the resultant OCTET STRING? With
> PKCS#7 I knew I had to use definite-length BER, but now?
> I would like to receive some information or comments on this matter.
> 
> Luciano Medina
> 



Received: by above.proper.com (8.11.6/8.11.3) id fBLJjHO21267 for ietf-smime-bks; Fri, 21 Dec 2001 11:45:17 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBLJjE221260 for <[e-mail]>; Fri, 21 Dec 2001 11:45:14 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Dec 2001 19:45:03 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA09740 for <[e-mail]>; Fri, 21 Dec 2001 14:45:16 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBLJjEP17186 for <[e-mail]>; Fri, 21 Dec 2001 14:45:14 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NAWL7>; Fri, 21 Dec 2001 14:45:14 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.36]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NAWLX; Fri, 21 Dec 2001 14:45:07 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Fri, 21 Dec 2001 14:44:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I talked to Don Davis today.  I am writing this note to share his reaction 
to my summary of this thread.

First, he is pleased to see the working group addressing the subject line 
issue.  While this issue was not part of his initial concerns, he agrees 
that it deserves a solution.

Second, he would like to see the working group mandate the inclusion of the 
TO, CC, and FROM lines whenever encryption and signature are used 
together.  As he explained in is I-D, he does not believe that many users 
are able to understand the interaction between signing, encrypting, or both 
(in either order).

Third, he would like to see the TO, CC, and FROM lines automatically 
processed by the receiving mail agent software.  While he acknowledges the 
issues associated with BCC, mail lists, and so on, he firmly believes that 
the people writing the software understand the situation much better than 
mass market e-mail users.

Fourth, he would like to see the working group mandate the inclusion of the 
TO, CC, and FROM lines whenever the sending agent or the receiving agent 
represents a human.  In other words, computer-to-computer communications 
may not need these to be protected.

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLJHtu20055 for ietf-smime-bks; Fri, 21 Dec 2001 11:17:55 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBLJHr220051 for <[e-mail]>; Fri, 21 Dec 2001 11:17:53 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Dec 2001 19:17:41 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA07824 for <[e-mail]>; Fri, 21 Dec 2001 14:17:54 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBLJHrR15060 for <[e-mail]>; Fri, 21 Dec 2001 14:17:53 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NAV08>; Fri, 21 Dec 2001 14:17:53 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.7]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NAV07; Fri, 21 Dec 2001 14:17:48 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Encoding of enhanced content types in CMS
Date: Fri, 21 Dec 2001 14:17:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In CMS, we anticipate the encapsulation of one content type with 
another.  In SMIME, there is in interposed MIME heading, so this capability 
is not used.  In other environments, CMS content types are directly 
encapsulated (see draft-ietf-smime-x400wrap-03.txt).

Russ

At 07:36 PM 12/21/2001 +0100, [e-mail] wrote:

>A major difference I find between CMS and PKCS#7 (from which CMS is
>derived) is the fact that in PKCS#7 it is well defined how to encode
>enhanced types to be used as content for another enhanced type.
>
>" Content types in the enhanced class contain content of some type
>(possibly encrypted), and other cryptographic enhancements. For example,
>enveloped-data content can contain (encrypted) signed-data content, which
>can contain data content. "
>
>Specifically, in Section "7.General Sintax", Note 2:
>
>" When a ContentInfo value is the inner content of signed-data,
>signed-and-enveloped-data, or digested-data content, a message-digest
>algorithm is applied to the contents octets of the DER encoding of the
>content field. When a ContentInfo value is the inner content of
>enveloped-data or signed-and-enveloped-data content, a content-encryption
>algorithm is applied to the contents octets of a definite-length BER
>encoding of the content field. "
>
>On the other hand. CMS does not define any encoding rules at all. The new
>draft of the CMS points out the question of compatibility with PKCS#7
>(section 5.2.1) with the inclusion or not of the tag and lenght octets in
>the encoding of a SEQUENCE in the encapContentInfo eContent field, but it
>eludes again the matter of which encoding rules should be used in CMS.
>Does not it implies that incompatibilities may arise between different
>implementations of CMS when the content processed (digested or encrypted)
>was other than Data? Suppose I receive a CMS EnvelopedData type, and the
>encryptedContentInfo contentType is SignedData. After the decryption
>process, how am I supposed to decode the resultant OCTET STRING? With
>PKCS#7 I knew I had to use definite-length BER, but now?
>I would like to receive some information or comments on this matter.
>
>Luciano Medina




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLILl616878 for ietf-smime-bks; Fri, 21 Dec 2001 10:21:47 -0800 (PST)
Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLILj216874 for <[e-mail]>; Fri, 21 Dec 2001 10:21:45 -0800 (PST)
Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id GOPHS103.SEQ for <[e-mail]>; Fri, 21 Dec 2001 19:24:01 +0100 
Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15) with ESMTP id GOPHHE00.Z3J for <[e-mail]>; Fri, 21 Dec 2001 19:17:38 +0100 
Subject: Encoding of enhanced content types in CMS
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 21 Dec 2001 19:36:13 +0100
X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.7 |March 21, 2001) at 21/12/2001 19:36:18
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A major difference I find between CMS and PKCS#7 (from which CMS is
derived) is the fact that in PKCS#7 it is well defined how to encode
enhanced types to be used as content for another enhanced type.

" Content types in the enhanced class contain content of some type
(possibly encrypted), and other cryptographic enhancements. For example,
enveloped-data content can contain (encrypted) signed-data content, which
can contain data content. "

Specifically, in Section "7.General Sintax", Note 2:

" When a ContentInfo value is the inner content of signed-data,
signed-and-enveloped-data, or digested-data content, a message-digest
algorithm is applied to the contents octets of the DER encoding of the
content field. When a ContentInfo value is the inner content of
enveloped-data or signed-and-enveloped-data content, a content-encryption
algorithm is applied to the contents octets of a definite-length BER
encoding of the content field. "

On the other hand. CMS does not define any encoding rules at all. The new
draft of the CMS points out the question of compatibility with PKCS#7
(section 5.2.1) with the inclusion or not of the tag and lenght octets in
the encoding of a SEQUENCE in the encapContentInfo eContent field, but it
eludes again the matter of which encoding rules should be used in CMS.
Does not it implies that incompatibilities may arise between different
implementations of CMS when the content processed (digested or encrypted)
was other than Data? Suppose I receive a CMS EnvelopedData type, and the
encryptedContentInfo contentType is SignedData. After the decryption
process, how am I supposed to decode the resultant OCTET STRING? With
PKCS#7 I knew I had to use definite-length BER, but now?
I would like to receive some information or comments on this matter.

Luciano Medina



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLHwPl16102 for ietf-smime-bks; Fri, 21 Dec 2001 09:58:25 -0800 (PST)
Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLHwN216098 for <[e-mail]>; Fri, 21 Dec 2001 09:58:23 -0800 (PST)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id fBLHuNK92409; Fri, 21 Dec 2001 09:56:23 -0800 (PST)
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: The ECC Document and the IESG
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 21 Dec 2001 09:56:23 -0800
In-Reply-To: "Housley, Russ"'s message of "Fri, 21 Dec 2001 11:58:40 -0500"
Message-ID: <[e-mail]>
Lines: 14
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Housley, Russ" <[e-mail]> writes:
> I am sending this note to make sure that all concerned are aware of the 
> situation.  This is also the time for anyone that thinks the ECC algorithms 
> document should be published on the Standards Track to speak up.  If I do 
> not hear objections by 2 January 2002, I will assume that publication of 
> the ECC algorithms document as an Informational RFC is acceptable.
I sgree with going to Informational.

-Ekr


-- 
[Eric Rescorla                                   [e-mail]]
                http://www.rtfm.com/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLH0U112481 for ietf-smime-bks; Fri, 21 Dec 2001 09:00:30 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBLH0S212476 for <[e-mail]>; Fri, 21 Dec 2001 09:00:28 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Dec 2001 17:00:16 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA27613 for <[e-mail]>; Fri, 21 Dec 2001 12:00:29 -0500 (EST)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBLH0Sw03748 for <[e-mail]>; Fri, 21 Dec 2001 12:00:28 -0500 (EST)
Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <V47AF006>; Fri, 21 Dec 2001 18:00:21 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NA4HZ; Fri, 21 Dec 2001 12:00:24 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 21 Dec 2001 11:58:40 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: The ECC Document and the IESG
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

During discussions last week at the IETF meeting, there were hallway 
discussions about whether the ECC algorithms document can be implemented 
without infringing on patents (or yet-to-be-issued patents).  During these 
hallway discussions, it became clear to me that the known patent holders 
are unable to make a statement that either confirms or denies the ability 
to create unencumbered ECC implementations.

As a result of this situation, I suggested that the ECC algorithms document 
be published as an Informational RFC.

The IESG met yesterday, and they discussed the ECC algorithms 
document.  Jeff Schiller explained the situation, and he explained desire 
for publication as an Informational RFC.  However, in my original request 
to the IESG, I had asked for publication as a Standards Track 
document.  This contradiction raised the question, "Does the WG know?"

I am sending this note to make sure that all concerned are aware of the 
situation.  This is also the time for anyone that thinks the ECC algorithms 
document should be published on the Standards Track to speak up.  If I do 
not hear objections by 2 January 2002, I will assume that publication of 
the ECC algorithms document as an Informational RFC is acceptable.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id fBKGHSO11628 for ietf-smime-bks; Thu, 20 Dec 2001 08:17:28 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKGHQ211620 for <[e-mail]>; Thu, 20 Dec 2001 08:17:26 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11085; Thu, 20 Dec 2001 11:17:24 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-07.txt
Date: Thu, 20 Dec 2001 11:17:24 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-07.txt
	Pages		: 23
	Date		: 17-Dec-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-07.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-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cmsalg-07.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id fBKGHOE11618 for ietf-smime-bks; Thu, 20 Dec 2001 08:17:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKGHN211614 for <[e-mail]>; Thu, 20 Dec 2001 08:17:23 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11071; Thu, 20 Dec 2001 11:17:21 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-06.txt
Date: Thu, 20 Dec 2001 11:17:21 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-06.txt
	Pages		: 52
	Date		: 17-Dec-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-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-rfc2630bis-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2630bis-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJK7jT15576 for ietf-smime-bks; Wed, 19 Dec 2001 12:07:45 -0800 (PST)
Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJK7i215572 for <[e-mail]>; Wed, 19 Dec 2001 12:07:44 -0800 (PST)
Received: from sdn-ar-002njhackp095.dialsprint.net ([168.191.60.183] helo=[168.191.59.169]) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Gn05-0006K7-00 for [e-mail]; Wed, 19 Dec 2001 12:07:37 -0800
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101003b846768bf45f@[168.191.59.169]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 19 Dec 2001 11:59:28 -0500
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: The subject line leakage problem
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is getting much more complicated than it needs to be, and is 
likely to break interoperability with non-enhanced clients.

The simplest thing to do is to say:
- Senders should put the minimum that they want in the unprotected headers
- Senders include as much as they want protected in a 
text/rfc822-header part at the beginning of a multipart/mixed message
- Enhanced clients should display the message with the headers from 
the text/rfc822-header part moved to where the user thinks he/she 
sees the headers. In the case of headers that are in both in the 822 
message and in the text/rfc822-header body part, the latter wins 
(because it is protected)
- The moved-up headers may cause side-effects that the MUA should act 
on. For example, if the Cc: in the 822 headers is "[e-mail]" 
but the Cc: in the protected headers is "[e-mail]", the "reply 
to all" action should include amy but not include bill.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJI1cN08132 for ietf-smime-bks; Wed, 19 Dec 2001 10:01:38 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJI1b208128 for <[e-mail]>; Wed, 19 Dec 2001 10:01:37 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 19 Dec 2001 10:01:13 -0800 (PST)
Date: Wed, 19 Dec 2001 09:51:06 -0800 (PST)
From: [e-mail]
Subject: Re: Re(2): The subject line leakage problem
In-reply-to: "Your message dated Tue, 18 Dec 2001 18:24:05 +0000" <"BARNOUIC:0684-011218182322-0010*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
To: Jim Craigie <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Now, in theory X.400 MTAs only deal with the envelope and are able to pass
> > arbitrary content types around, making it possible to introduce new ones at any
> > time. Howevr, I've found that sometimes this works in practice and often it
> > doesn't. Support for this in real world X.400 implementations is far from
> > uniform. At least part of the reason why this is so is because this capability
> > is rarely used, and rarely used capabilities are bound to have bugs, especially
> > given that most X.400 implementations are rarely updated these days.

> I don't know what X.400 systems you are basing the above comment on. I've
> been involved with interoperability testing STANAG 4406 PCT (just CMS really),
> and we have not seen a single problem with an X.400 MTA being unable to relay
> the new content type.

Well, maybe things have improved. It has been some time since I wrote the
support for this in PMDF-X400 and I no longer recall the specifics, but I don't
believe I was ever successful in getting this to work with another MTA. I
would have tried MAILbus 400 at a minimum and probably Exchange; the
exact timing of the work would have determined which of the several dozen
other MTAs were available for testing at the time.

> > There are, however, things you can do in SMTP. One of them is to secure
> > a batch SMTP session (RFC 2442). There are a number of email systems
> > that support this approach. I suppose something similar is possible in
> > X.400 (a P1 content type?), but AFAIK nobody has ever defined such a
> > thing.

> The X.400 standard defines a double-envelope content-type precisely to allow
> protection of the envelope where required.

Interesting. I don't recall that being possible. There is a way to nest
messages, but I didn't believe the support for included envelope information
was sufficient for it to be used for this.

				Ned



Received: by above.proper.com (8.11.6/8.11.3) id fBIKWCH28847 for ietf-smime-bks; Tue, 18 Dec 2001 12:32:12 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBIKWA228842 for <[e-mail]>; Tue, 18 Dec 2001 12:32:10 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Dec 2001 20:32:01 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA10261 for <[e-mail]>; Tue, 18 Dec 2001 15:32:12 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBIKWA805280 for <[e-mail]>; Tue, 18 Dec 2001 15:32:11 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61M0N3C>; Tue, 18 Dec 2001 15:32:07 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.20 [10.3.1.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61M0NN5; Tue, 18 Dec 2001 15:32:01 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Jim Craigie <[e-mail]>
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Tue, 18 Dec 2001 15:26:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

I have had a lot of experience in this area, and I am glad to hear that new 
product releases have repaired this major shortcoming.  I have personally 
been bit by this by more than one product.

I do not think that MTA architectures are the main point of this thread, so 
lets see if we can get back to the S/MIME and CMS issues...

Russ


At 06:24 PM 12/18/2001 +0000, Jim Craigie wrote:
> > Now, in theory X.400 MTAs only deal with the envelope and are able to
pass
> > arbitrary content types around, making it possible to introduce new 
> ones at any
> > time. Howevr, I've found that sometimes this works in practice and often
it
> > doesn't. Support for this in real world X.400 implementations is far
from
> > uniform. At least part of the reason why this is so is because this 
> capability
> > is rarely used, and rarely used capabilities are bound to have bugs, 
> especially
> > given that most X.400 implementations are rarely updated these days.
>
>I don't know what X.400 systems you are basing the above comment on. I've 
>been involved with interoperability testing STANAG 4406 PCT (just CMS 
>really), and we have not seen a single problem with an X.400 MTA being 
>unable to relay the new content type.




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIKWBP28843 for ietf-smime-bks; Tue, 18 Dec 2001 12:32:11 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBIKW9228834 for <[e-mail]>; Tue, 18 Dec 2001 12:32:09 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Dec 2001 20:31:59 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA10248 for <[e-mail]>; Tue, 18 Dec 2001 15:32:10 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBIKW8805273 for <[e-mail]>; Tue, 18 Dec 2001 15:32:08 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61M0N3A>; Tue, 18 Dec 2001 15:32:07 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.20 [10.3.1.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61M0NNY; Tue, 18 Dec 2001 15:32:00 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Jim Craigie <[e-mail]>
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Tue, 18 Dec 2001 15:24:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

I was thinking about the upcoming need to support international character 
sets.  The DNS is going to support more than ASCII in the near future.

Russ

At 06:11 PM 12/18/2001 +0000, Jim Craigie wrote:
> > I would like to steer this discussion toward a signed attribute (a
CHOICE
> > of IA5String and UTF8String (for international characters that are
coming
> > soon)).
>
>Since ASCII characters are encoded identically in a UTF8String and an 
>IA5String there is no need to introduce a CHOICE - keep it simple and just 
>define the syntax as UTF8String.




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIIO6t22464 for ietf-smime-bks; Tue, 18 Dec 2001 10:24:06 -0800 (PST)
Received: from tube.clearswift.com (tube.clearswift.com [195.153.60.158]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIIO4222457 for <[e-mail]>; Tue, 18 Dec 2001 10:24:04 -0800 (PST)
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.clearswift.com (4.6.0.87) with ESMTP id  for <[e-mail]>; Tue, 18 Dec 2001 18:22:07 GMT
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Tue, 18 Dec 2001 18:24:05 +0000
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Tue, 18 Dec 2001 18:24:05 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Tue, 18 Dec 2001 18:24:05 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0057-011218182405-09d4]
X400-Content-Type: P2-1988 (22)
X400-Originator: [e-mail]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [e-mail]
Date: Tue, 18 Dec 2001 18:24:05 +0000
X400-Content-Identifier: Re(2): The subje
Message-Id: <"BARNOUIC:0684-011218182322-0010*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
From: Jim Craigie <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Subject: Re(2): The subject line leakage problem
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Now, in theory X.400 MTAs only deal with the envelope and are able to pass
> arbitrary content types around, making it possible to introduce new ones at any
> time. Howevr, I've found that sometimes this works in practice and often it
> doesn't. Support for this in real world X.400 implementations is far from
> uniform. At least part of the reason why this is so is because this capability
> is rarely used, and rarely used capabilities are bound to have bugs, especially
> given that most X.400 implementations are rarely updated these days.

I don't know what X.400 systems you are basing the above comment on. I've been involved with interoperability testing STANAG 4406 PCT (just CMS really), and we have not seen a single problem with an X.400 MTA being unable to relay the new content type. 

> There are, however, things you can do in SMTP. One of them is to secure
> a batch SMTP session (RFC 2442). There are a number of email systems
> that support this approach. I suppose something similar is possible in 
> X.400 (a P1 content type?), but AFAIK nobody has ever defined such a 
> thing.

The X.400 standard defines a double-envelope content-type precisely to allow protection of the envelope where required.

Jim




Received: by above.proper.com (8.11.6/8.11.3) id fBIIIVg21842 for ietf-smime-bks; Tue, 18 Dec 2001 10:18:31 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBIIIO221823 for <[e-mail]>; Tue, 18 Dec 2001 10:18:24 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Dec 2001 18:18:14 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA28155 for <[e-mail]>; Tue, 18 Dec 2001 13:18:26 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBIIIOJ21591 for <[e-mail]>; Tue, 18 Dec 2001 13:18:24 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61M0K7B>; Tue, 18 Dec 2001 13:18:24 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61M0K7A; Tue, 18 Dec 2001 13:18:22 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: The subject line leakage problem
Date: Tue, 18 Dec 2001 13:18:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned:

Thanks for correcting the details.

RFC 822 defines a header, which is clearly outside the SMTP envelope.  The 
RFC 822 header is separated from the content by a blank line.  The subject 
line is before this blank line, so it cannot be protected by a content 
encapsulation protocol.

Sorry for any confusion that may have resulted from the loose terminology 
in my first message.

Russ

At 09:28 AM 12/18/2001 -0800, [e-mail] wrote:
> > The subject line issue is not a problem in the X.400 world.  SMTP
carries
> > the subject line is in the envelope.
>
>On the contrary, in SMTP the subject field is part of the content, not part
>of the envelope. Specifically, it is part of the message header.
>
> > The corresponding X.400 protocols
> > (P1, P3, and P7) do not.  In X.400, the subject line is part of the 
> content.
>
>This part is correct, but it fails to get at the reason why X.400 and SMTP
>differ in their ability to protect the entire content of a message end to
>end.




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: by above.proper.com (8.11.6/8.11.3) id fBIIBOT21199 for ietf-smime-bks; Tue, 18 Dec 2001 10:11:24 -0800 (PST)
Received: from tube.clearswift.com (tube.clearswift.com [195.153.60.158]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIIBJ221191 for <[e-mail]>; Tue, 18 Dec 2001 10:11:20 -0800 (PST)
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.clearswift.com (4.6.0.87) with ESMTP id  for <[e-mail]>; Tue, 18 Dec 2001 18:09:33 GMT
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Tue, 18 Dec 2001 18:11:43 +0000
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Tue, 18 Dec 2001 18:11:43 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Tue, 18 Dec 2001 18:11:43 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0057-011218181143-09d3]
X400-Content-Type: P2-1988 (22)
X400-Originator: [e-mail]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [e-mail]
Date: Tue, 18 Dec 2001 18:11:43 +0000
X400-Content-Identifier: Re(2): The subje
Message-Id: <"BARNOUIC:0684-011218181101-000f*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
From: Jim Craigie <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re(2): The subject line leakage problem
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The subject line issue is not a problem in the X.400 world.  SMTP carries 
> the subject line is in the envelope.  The corresponding X.400 protocols 
> (P1, P3, and P7) do not.  In X.400, the subject line is part of the content.
> 
> X.400 does have similar issues with TO, CC, and FROM.  Both SMTP and 
> X.400 would like to integrity protect these.
> 
> Russ

X.400 also carries TO, CC, and FROM in the content.

> I would like to steer this discussion toward a signed attribute (a CHOICE 
> of IA5String and UTF8String (for international characters that are coming 
> soon)).

Since ASCII characters are encoded identically in a UTF8String and an IA5String there is no need to introduce a CHOICE - keep it simple and just define the syntax as UTF8String.

> My initial cut at the header lines that ought to be included are FROM, 

When displaying the originator of a signed message. S/MIME clients should display the Name + RFC822Address from SubjectAltName from the Certificate that signed the message in place of the FROM from the RFC822 Header. They should do the same e.g. when constructing a reply. So I can see little point adding the FROM into this proposed signed attribute. And I think that Paul Hoffman's proposal (reproduced below) is more general, and altogether a better solution.

> Instead, how about encouraging the use of multipart/mixed which 
> starts with text/rfc822-headers. Any headers in that first part are 
> to replace the same headers on display only.

Jim




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIHrca20688 for ietf-smime-bks; Tue, 18 Dec 2001 09:53:38 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIHra220684 for <[e-mail]>; Tue, 18 Dec 2001 09:53:36 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 18 Dec 2001 09:53:37 -0800 (PST)
Date: Tue, 18 Dec 2001 09:28:54 -0800 (PST)
From: [e-mail]
Subject: RE: The subject line leakage problem
In-reply-to: "Your message dated Tue, 18 Dec 2001 10:28:20 -0500" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The subject line issue is not a problem in the X.400 world.  SMTP carries
> the subject line is in the envelope.

On the contrary, in SMTP the subject field is part of the content, not part
of the envelope. Specifically, it is part of the message header.

> The corresponding X.400 protocols
> (P1, P3, and P7) do not.  In X.400, the subject line is part of the content.

This part is correct, but it fails to get at the reason why X.400 and SMTP
differ in their ability to protect the entire content of a message end to
end.

The real reason the two differ is that X.400, unlike SMTP, in theory supports
the transmission of completely different forms of messages. Because of this you
can define, say, a new type of message for EDI. Or voice mail. These things are
called content types in X.400 parlance (not to be confused with a MIME content
type, which is a different thing). Any new content type can carry other content
within it, so a new content type can be nothing but a security enclosure with
the actual content nested inside. Several such security enclosures have been
defined, making it possible to secure X.400 as a whole just underneath the
envelope.

Now, in theory X.400 MTAs only deal with the envelope and are able to pass
arbitrary content types around, making it possible to introduce new ones at any
time. Howevr, I've found that sometimes this works in practice and often it
doesn't. Support for this in real world X.400 implementations is far from
uniform. At least part of the reason why this is so is because this capability
is rarely used, and rarely used capabilities are bound to have bugs, especially
given that most X.400 implementations are rarely updated these days.

SMTP doesn't have this ability to carry arbitrary sorts of messages around.
However, it isn't because it is impossible to add to SMTP or adding it hasn't
been considered. It is possible and it has been considered. The problem is that
it would mean upgrading every SMTP server out there to support it, and this was
and is not considered to be a viable thing to do. Because of this we instead
choose to use MIME facilities to define a security enclosure for SMTP. These
can be used to protect the subject and so forth, but it isn't as clean as the
X.400 scheme. It does, however, interoperate with existing SMTP servers, which
was and is a huge win.

> X.400 does have similar issues with TO, CC, and FROM.  Both SMTP and X.400
> would like to integrity protect these.

If you're talking about header fields, then the issues for X.400 and SMTP
protection of this information are the same as for subject lines. If, on the
other hand, you're talking about envelope information, then yes, this is a
problem. There are various solutions in this space, but short of deploying a
public key infrastructure that every MTA can use to verify signed recipient
information, there is no real way to completely address the problem.

There are, however, things you can do in SMTP. One of them is to secure
a batch SMTP session (RFC 2442). There are a number of email systems
that support this approach. I suppose something similar is possible in 
X.400 (a P1 content type?), but AFAIK nobody has ever defined such a thing.

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIFScR10111 for ietf-smime-bks; Tue, 18 Dec 2001 07:28:38 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBIFSa210107 for <[e-mail]>; Tue, 18 Dec 2001 07:28:37 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Dec 2001 15:28:26 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA11359 for <[e-mail]>; Tue, 18 Dec 2001 10:28:37 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBIFSaJ02309 for <[e-mail]>; Tue, 18 Dec 2001 10:28:36 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61M0H5X>; Tue, 18 Dec 2001 10:28:36 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61M0H5V; Tue, 18 Dec 2001 10:28:30 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: The subject line leakage problem
Date: Tue, 18 Dec 2001 10:28:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

The subject line issue is not a problem in the X.400 world.  SMTP carries 
the subject line is in the envelope.  The corresponding X.400 protocols 
(P1, P3, and P7) do not.  In X.400, the subject line is part of the content.

X.400 does have similar issues with TO, CC, and FROM.  Both SMTP and X.400 
would like to integrity protect these.

Russ


At 09:40 PM 12/17/2001 -0800, Jim Schaad wrote:


> >
> > At 1:37 PM -0800 12/17/01, Hallam-Baker, Phillip wrote:
> > >On the 'replace other headers', the problem there is that we
> > end up back in
> > >the rat-hole. People will propose all sorts of random
> > headers ad infinitum.
> >
> > That doesn't matter because RFC 2822 allows you to add as many
> > ill-conceived headers as you want to a message.
> >
> > >And others will counter that there are integrity problems
> > and then we have
> > >the interop issue, etc.
> >
> > There is no interop issue. What I proposed was that headers found in
> > the body part be *displayed* in the message, not substituted into the
> > message for storage. It's a user presentation hack, not a message
> > format hack.
> >
> > >I don't think that the problem is big enough to require a
> > whole new S/MIME
> > >spec to solve, just a minor tweak to implementations.
> >
> > Fully agree.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >
>
>First, this is an issue for signed as well as encrypted messages.  You
>want to protect the subject for signed messages as well as hide the
>subject for encrypted messages.
>
>Second, the solution of putting items here solves the problem for
>MIME/Internet mail.  But I think that we need to ask the X.400
>communities if they want the problem solved for them as well.
>
>Third, I worry about what happens for forms type messages.  Using the
>multipart may take care of this however.  We initially had a "bug" in
>Microsoft Outlook Express where we place the 822 headers in the body of
>the message, and then populated the display headers from this
>information.  I agree that this is a bad solution and should not be
>persued.
>
>Jim




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIFE0V09510 for ietf-smime-bks; Tue, 18 Dec 2001 07:14:00 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBIFDw209506 for <[e-mail]>; Tue, 18 Dec 2001 07:13:59 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Dec 2001 15:13:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA09958 for <[e-mail]>; Tue, 18 Dec 2001 10:13:56 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBIFDsJ00702 for <[e-mail]>; Tue, 18 Dec 2001 10:13:54 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61M0HSC>; Tue, 18 Dec 2001 10:13:54 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61M0HR6; Tue, 18 Dec 2001 10:13:46 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: Re: The subject line leakage problem
Date: Tue, 18 Dec 2001 09:42:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phil:

Thanks for raising this issue.

After the intended-recipients discussion, it was clear to me that several 
RFC 821 header lines needed various forms of protection.  The level of 
automated checking is different for each of them.  Some need 
confidentiality, and others do not (and cannot without disrupting the mail 
delivery).

I would like to steer this discussion toward a signed attribute (a CHOICE 
of IA5String and UTF8String (for international characters that are coming 
soon)).  The attribute would contain a subset of the header lines.

My initial cut at the header lines that ought to be included are FROM, TO, 
CC, SUBJECT, and DATE.  So, for Phil's message that started this thread, 
the attribute would contain:

     From: "Hallam-Baker, Phillip" <[e-mail]>
     To:
     Cc: [e-mail]
     Subject: The subject line leakage problem
     Date: Mon, 17 Dec 2001 10:34:39 -0800

I think that the content-hints attribute defined in RFC 2634 should be used 
to carry the real subject line when the RFC 821 header carries a masked 
subject line.

Russ


At 10:34 AM 12/17/2001 -0800, Hallam-Baker, Phillip wrote:
>All,
>
>         One of the ongoing problems with people using PGP is that people
put
>confidential information in the mail subject lines, eg:
>
>Subject: Proposed purchase of Excite@Home
>Subject: Your STD test results
>Subject: Planned head count reduction
>
>         etc.
>
>So over the years there have been plenty of fixes involving CMS encrypted
>attributes etc. which gets into the rat hole of what other headers to add
>in.
>
>So instead of that how about the following fix:
>
>1) A Best Current Practice Draft that says
>2) Clients SHOULD offer users the option of replacing the subject line on
>confidential messages and carrying the subject as the first line in the
body
>of the message.
>
>
>So the above message would become
>
>Subject: Confidential
>Subject: Confidential
>Subject: Confidential
>
>And when opened we get something like:
>
>Subject: Confidential
>
>Subject: Proposed purchase of Excite@Home
>
>Alice,
>         Yadda Yadda Yadda ....
>
>
>         So, no need for any modification of existing specs, complete
>backwards interop and the bug in the spec gets fixed.
>
>                 Phill
>
>Phillip Hallam-Baker FBCS C.Eng.
>Principal Scientist
>VeriSign Inc.
>[e-mail]
>781 245 6996 x227
>
>
>




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBI5fAT17586 for ietf-smime-bks; Mon, 17 Dec 2001 21:41:10 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI5f8217580; Mon, 17 Dec 2001 21:41:09 -0800 (PST)
Received: from revelation ([12.230.197.121]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011218054057.FOTI403.rwcrmhc52.attbi.com@revelation>; Tue, 18 Dec 2001 05:40:57 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "'Hallam-Baker, Phillip'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: The subject line leakage problem
Date: Mon, 17 Dec 2001 21:40:41 -0800
Message-ID: <000001c18786$885abd20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <p05101022b84416db7e81@[165.227.249.20]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> At 1:37 PM -0800 12/17/01, Hallam-Baker, Phillip wrote:
> >On the 'replace other headers', the problem there is that we 
> end up back in
> >the rat-hole. People will propose all sorts of random 
> headers ad infinitum.
> 
> That doesn't matter because RFC 2822 allows you to add as many 
> ill-conceived headers as you want to a message.
> 
> >And others will counter that there are integrity problems 
> and then we have
> >the interop issue, etc.
> 
> There is no interop issue. What I proposed was that headers found in 
> the body part be *displayed* in the message, not substituted into the 
> message for storage. It's a user presentation hack, not a message 
> format hack.
> 
> >I don't think that the problem is big enough to require a 
> whole new S/MIME
> >spec to solve, just a minor tweak to implementations.
> 
> Fully agree.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

First, this is an issue for signed as well as encrypted messages.  You
want to protect the subject for signed messages as well as hide the
subject for encrypted messages.

Second, the solution of putting items here solves the problem for
MIME/Internet mail.  But I think that we need to ask the X.400
communities if they want the problem solved for them as well.

Third, I worry about what happens for forms type messages.  Using the
multipart may take care of this however.  We initially had a "bug" in
Microsoft Outlook Express where we place the 822 headers in the body of
the message, and then populated the display headers from this
information.  I agree that this is a bad solution and should not be
persued.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHNgEf04314 for ietf-smime-bks; Mon, 17 Dec 2001 15:42:14 -0800 (PST)
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHNgA204306; Mon, 17 Dec 2001 15:42:11 -0800 (PST)
Received: from dhcp128.extundo.com ([195.42.214.241]) (authenticated bits=0) by yxa.extundo.com (8.12.1/8.12.1) with ESMTP id fBHNg93O007459; Tue, 18 Dec 2001 00:42:13 +0100
To: "Hallam-Baker, Phillip" <[e-mail]>
Cc: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: Re: The subject line leakage problem
References: <[e-mail]>
From: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]> ("Hallam-Baker, Phillip"'s message of "Mon, 17 Dec 2001 13:37:19 -0800")
Date: Tue, 18 Dec 2001 00:40:28 +0100
Message-ID: <[e-mail]>
Lines: 25
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.50 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hallam-Baker, Phillip" <[e-mail]> writes:

> Yes, the only problem we are dealling with here is confidentiality.
>
> On the 'replace other headers', the problem there is that we end up back in
> the rat-hole. People will propose all sorts of random headers ad infinitum.
> And others will counter that there are integrity problems and then we have
> the interop issue, etc.
>
> I don't think that the problem is big enough to require a whole new S/MIME
> spec to solve, just a minor tweak to implementations.

I agree that this is a problem for email clients, but I also believe
that this could be solved by implementation recomendations.  Always
wrapping the intended mail as a message/rfc822 part inside the
encrypted part could be a solution.  The problem with this seem to be
that most clients doesn't handle message/rfc822 in any intelligent
way.

While we are on the topic of MIME and encryption -- does anyone know
the history behind S/MIME not using multipart/encrypted of RFC 1847
for encrypted data?  This decision causes some pain when implementing
a client that supports both PGP and CMS; S/MIME encryption becomes a
special case.  Multipart/encrypted doesn't seem to have been discussed
here, judging by the mail archives at least.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHMubh01600 for ietf-smime-bks; Mon, 17 Dec 2001 14:56:37 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMuZ201590; Mon, 17 Dec 2001 14:56:36 -0800 (PST)
Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA14726; Mon, 17 Dec 2001 17:54:10 -0500 (EST)
Date: Mon, 17 Dec 2001 17:56:30 -0500
From: Cyrus Daboo <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
cc: [e-mail]
Subject: Re: The subject line leakage problem
Message-ID: <[e-mail]>
In-Reply-To: <p05101021b8440ce929b7@[165.227.249.20]>
References: <[e-mail]> <p05101021b8440ce929b7@[165.227.249.20]>
X-Mailer: Mulberry/3.0.0d1 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, December 17, 2001 1:07 PM -0800 "Paul Hoffman / IMC" 
<[e-mail]> wrote:

> Instead, how about encouraging the use of multipart/mixed which starts
> with text/rfc822-headers. Any headers in that first part are to replace
> the same headers on display only.

I think a better solution is to encapsulate the original message as a 
message/rfc822 part within an outer message, whose headers can be arbitrary 
(within the bounds of rfc2822). Then the recommendation would be for 
clients to present the embedded message/rfc822 part as the 'real' message 
to the user when the message/rfc822 is at the top-level of the MIME 
structure. This also has the advantage that it makes it easier to store the 
original message (header and content), throwing away the outer header, if 
needed, without having to 'reconstruct' it from the multipart/mixed, 
text/rfc822-headers .... construct you suggest.

-- 
Cyrus Daboo


Received: by above.proper.com (8.11.6/8.11.3) id fBHMFlG27999 for ietf-smime-bks; Mon, 17 Dec 2001 14:15:47 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMFj227987; Mon, 17 Dec 2001 14:15:45 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101022b84416db7e81@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 17 Dec 2001 13:42:46 -0800
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: The subject line leakage problem
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:37 PM -0800 12/17/01, Hallam-Baker, Phillip wrote:
>On the 'replace other headers', the problem there is that we end up back in
>the rat-hole. People will propose all sorts of random headers ad infinitum.

That doesn't matter because RFC 2822 allows you to add as many 
ill-conceived headers as you want to a message.

>And others will counter that there are integrity problems and then we have
>the interop issue, etc.

There is no interop issue. What I proposed was that headers found in 
the body part be *displayed* in the message, not substituted into the 
message for storage. It's a user presentation hack, not a message 
format hack.

>I don't think that the problem is big enough to require a whole new S/MIME
>spec to solve, just a minor tweak to implementations.

Fully agree.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHLanj26919 for ietf-smime-bks; Mon, 17 Dec 2001 13:36:49 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHLal226912; Mon, 17 Dec 2001 13:36:48 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id fBHLXZs01419; Mon, 17 Dec 2001 13:33:35 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2W27W4Z>; Mon, 17 Dec 2001 13:37:31 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: RE: The subject line leakage problem
Date: Mon, 17 Dec 2001 13:37:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18743.011DBFD0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C18743.011DBFD0
Content-Type: text/plain;
	charset="iso-8859-1"

Aggk!

Yes of course I meant S/MIME. Result of having just spent time explaining
why Pretty Good Privacy is not a first choice for solving problems of
document authenticity (think PGP code signing).

Yes, the only problem we are dealling with here is confidentiality.

On the 'replace other headers', the problem there is that we end up back in
the rat-hole. People will propose all sorts of random headers ad infinitum.
And others will counter that there are integrity problems and then we have
the interop issue, etc.

I don't think that the problem is big enough to require a whole new S/MIME
spec to solve, just a minor tweak to implementations.


	Phill

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


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Monday, December 17, 2001 4:08 PM
> To: Hallam-Baker, Phillip
> Cc: [e-mail]
> Subject: Re: The subject line leakage problem
> 
> 
> At 10:34 AM -0800 12/17/01, Hallam-Baker, Phillip wrote:
> >	One of the ongoing problems with people using PGP
> 
> Or S/MIME, which is the topic of this mailing list :-)
> 
> >  is that people put
> >confidential information in the mail subject lines, eg:
> >
> >Subject: Proposed purchase of Excite@Home
> >Subject: Your STD test results
> >Subject: Planned head count reduction
> >
> >	etc.
> >
> >So over the years there have been plenty of fixes involving 
> CMS encrypted
> >attributes etc. which gets into the rat hole of what other 
> headers to add
> >in.
> 
> Just to be clear: you are talking about leaking headers in 
> *encrypted* messages, not signed messages, I assume.
> 
> >So instead of that how about the following fix:
> >
> >1) A Best Current Practice Draft that says
> >2) Clients SHOULD offer users the option of replacing the 
> subject line on
> >confidential messages and carrying the subject as the first 
> line in the body
> >of the message.
> 
> A few thoughts:
> 
> 1) That only covers the subject; you might want to cover other 
> headers that have valuable information.
> 
> 2) That prevents the headers from being automatically processed.
> 
> Instead, how about encouraging the use of multipart/mixed which 
> starts with text/rfc822-headers. Any headers in that first part are 
> to replace the same headers on display only.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


------_=_NextPart_000_01C18743.011DBFD0
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:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C18743.011DBFD0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHL8dA25836 for ietf-smime-bks; Mon, 17 Dec 2001 13:08:39 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHL8b225830; Mon, 17 Dec 2001 13:08:37 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101021b8440ce929b7@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 17 Dec 2001 13:07:36 -0800
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: The subject line leakage problem
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:34 AM -0800 12/17/01, Hallam-Baker, Phillip wrote:
>	One of the ongoing problems with people using PGP

Or S/MIME, which is the topic of this mailing list :-)

>  is that people put
>confidential information in the mail subject lines, eg:
>
>Subject: Proposed purchase of Excite@Home
>Subject: Your STD test results
>Subject: Planned head count reduction
>
>	etc.
>
>So over the years there have been plenty of fixes involving CMS encrypted
>attributes etc. which gets into the rat hole of what other headers to add
>in.

Just to be clear: you are talking about leaking headers in 
*encrypted* messages, not signed messages, I assume.

>So instead of that how about the following fix:
>
>1) A Best Current Practice Draft that says
>2) Clients SHOULD offer users the option of replacing the subject line on
>confidential messages and carrying the subject as the first line in the body
>of the message.

A few thoughts:

1) That only covers the subject; you might want to cover other 
headers that have valuable information.

2) That prevents the headers from being automatically processed.

Instead, how about encouraging the use of multipart/mixed which 
starts with text/rfc822-headers. Any headers in that first part are 
to replace the same headers on display only.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBHIY9L17255 for ietf-smime-bks; Mon, 17 Dec 2001 10:34:09 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHIY7217250 for <[e-mail]>; Mon, 17 Dec 2001 10:34:07 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id fBHIUts23828 for <[e-mail]>; Mon, 17 Dec 2001 10:30:55 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2W273XR>; Mon, 17 Dec 2001 10:34:50 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: 
Cc: [e-mail]
Subject: The subject line leakage problem
Date: Mon, 17 Dec 2001 10:34:39 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18729.7C7732C0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C18729.7C7732C0
Content-Type: text/plain;
	charset="iso-8859-1"

All,

	One of the ongoing problems with people using PGP is that people put
confidential information in the mail subject lines, eg:

Subject: Proposed purchase of Excite@Home
Subject: Your STD test results
Subject: Planned head count reduction

	etc.

So over the years there have been plenty of fixes involving CMS encrypted
attributes etc. which gets into the rat hole of what other headers to add
in.

So instead of that how about the following fix:

1) A Best Current Practice Draft that says
2) Clients SHOULD offer users the option of replacing the subject line on
confidential messages and carrying the subject as the first line in the body
of the message.


So the above message would become

Subject: Confidential
Subject: Confidential
Subject: Confidential

And when opened we get something like:

Subject: Confidential

Subject: Proposed purchase of Excite@Home

Alice, 
	Yadda Yadda Yadda ....


	So, no need for any modification of existing specs, complete
backwards interop and the bug in the spec gets fixed.

		Phill

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



------_=_NextPart_000_01C18729.7C7732C0
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:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C18729.7C7732C0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBF1REx11575 for ietf-smime-bks; Fri, 14 Dec 2001 17:27:14 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBF1RD211570 for <[e-mail]>; Fri, 14 Dec 2001 17:27:13 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id fBF1REH16660; Fri, 14 Dec 2001 17:27:14 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3217 on Triple-DES and RC2 Key Wrapping
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 14 Dec 2001 17:27:14 -0800
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


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


        RFC 3217

        Title:	    Triple-DES and RC2 Key Wrapping
        Author(s):  R. Housley
        Status:     Informational
	Date:       December 2001
        Mailbox:    [e-mail]
        Pages:      9
        Characters: 19855
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-key-wrap-01.txt

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


This document specifies the algorithm for wrapping one Triple-DES
key with another Triple-DES key and the algorithm for wrapping
one RC2 key with another RC2 key.  These key wrap algorithms
were originally published in section 12.6 of RFC 2630.  They
are republished since these key wrap algorithms have been found to be
useful in contexts beyond those supported by RFC 2630.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3217

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

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBF1LgF11500 for ietf-smime-bks; Fri, 14 Dec 2001 17:21:42 -0800 (PST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBF1Le211496 for <[e-mail]>; Fri, 14 Dec 2001 17:21:40 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id fBF1LgH14886; Fri, 14 Dec 2001 17:21:42 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3211 on Password-based Encryption for CMS
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 14 Dec 2001 17:21:42 -0800
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


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


        RFC 3211

        Title:	    Password-based Encryption for CMS
        Author(s):  P. Gutmann
        Status:     Proposed Standard
	Date:       December 2001
        Mailbox:    [e-mail]
        Pages:      17
        Characters: 30527
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-password-06.txt

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


This document provides a method of encrypting data using user-supplied
passwords and, by extension, any form of variable-length keying
material which is not necessarily an algorithm-specific fixed-format
key.  The Cryptographic Message Syntax data format does not currently
contain any provisions for password-based data encryption.

This document is a product of the S/MIME Mail Security Workring 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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3211

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

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: by above.proper.com (8.11.6/8.11.3) id fBDH6G804685 for ietf-smime-bks; Thu, 13 Dec 2001 09:06:16 -0800 (PST)
Received: from localhost.localdomain (251-196-131-12.bellhead.com [12.131.196.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDH6E204680 for <[e-mail]>; Thu, 13 Dec 2001 09:06:14 -0800 (PST)
Received: from revelation (47-203-131-12.bellhead.com [12.131.203.47]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDH3Lj20224; Thu, 13 Dec 2001 10:03:21 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: Cryptographic Message Syntax to Proposed Standard
Date: Thu, 13 Dec 2001 10:05:54 -0700
Message-ID: <003f01c183f8$73e155c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Two last call comments:

Draft-ietf-smime-rfc2630bis-05.txt

In section 5.3 the discussion of the signedAttrs field the following
sentence occurs "Each SignedAttribute in the SET MUST be DER encoded."
There are two problems with the statement.  First there is no
SignedAttribute field or structure.  Second, this statement does not
make sense.  It should either be "Each AttributeValue" or "The
SignedAttributes set MUST be DER encoded for tranmission as well as
signature processing." 

Working group straw poll at the IETF meeting prefered the second
alternative.

Draft-ietf-smime-cmsalg-06.txt

In section 6.1 there is a discussion that CMS implemenations must accept
parameters as both NULL and absent for parsing.  There should be a
matching statement that CMS implementations SHOULD generate NULL
parameters.  [This could be absent as well, I don't currently have any
preference as to which option is chosen.]

Jim Schaad


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of The IESG
> Sent: Thursday, November 08, 2001 2:46 PM
> To: IETF-Announce:
> Cc: [e-mail]
> Subject: Last Call: Cryptographic Message Syntax to Proposed Standard
> 
> 
> 
> 
> The IESG has received a request from the S/MIME Mail Security Working
> Group to consider the following as Proposed Standards:
> 
>  o Cryptographic Message Syntax
> 	<draft-ietf-smime-rfc2630bis-05.txt>
>  o Cryptographic Message Syntax (CMS) Algorithms
> 	<draft-ietf-smime-cmsalg-06.txt>
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by November 21, 2001.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-05.txt
> http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-06.txt
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCNc7l14667 for ietf-smime-bks; Wed, 12 Dec 2001 15:38:07 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBCNc0214661 for <[e-mail]>; Wed, 12 Dec 2001 15:38:00 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Dec 2001 23:37:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA11899; Wed, 12 Dec 2001 18:34:10 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBCNY9M29554; Wed, 12 Dec 2001 18:34:09 -0500 (EST)
Received: by EXNA00 with Internet Mail Service (5.5.2653.19) id <YYYKM77S>; Wed, 12 Dec 2001 18:34:08 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YYYKM77Q; Wed, 12 Dec 2001 18:34:00 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "Sean P. Turner" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Input desired on symkeydist?
Date: Wed, 12 Dec 2001 18:33:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean:

Please post the updated draft.  I consider them early IETF Last Call
comments.

Russ


At 10:42 AM 12/12/2001 -0500, Sean P. Turner wrote:

>Here are some editorial comments on the symkeydist-06 draft.  I'll defer
>to Russ as to how to handle these.
>
>"Yee, Peter" wrote:
>
> > Page 3, para 2, 2nd sentence, change "ReipientInfo" to "RecipientInfo".
>
>Fixed
>
> > Page 3, para 2, metadiscussion, is it appropriate to jump in with ktri
and
> > kari this early in the document?
>
>I thought it was a good lead in to explain the difference between the
>ktri | kari and kekri.  I figured most people from the S/MIME group
>would be fully aware of the other two choices but maybe not the kekri.
>
> > Page 3, para 2, last sentence, change (twice) "their" to "its".
>
>Fixed
>
> > Page 4, para 1, you state that the security provided "is only as good 
> as the
> > sum...".  I content that it "is only as good as the weakest protection
> > mechanism employed."  The KEK only has to be retrieved from the holder
with
> > the weakest protections to be compromised.
>
>We're basically trying to say it's the sum of weakest people on the
>list. Unfortunately, right now the english is escaping me.
>
> > Page 4, section 1.2, 1st sentence, change "Light Weight" to
"Lightweight".
>
>Fixed
>
> > Page 4, section 1.2, 2nd sentence, change "any one" to "anyone".
>
>Fixed
>
> > Page 5, scenario 2, are the "S" keys the same.  I don't believe so, in 
> which
> > case I would label one "S1" and the other "S2".
>
>Actually I was thinking they were, but they don't have to be the same.
>They could be different.  Is it worth adding:
>"The key used by the originator could either be a key shared amongst all
>recipients or just between the member and the MLA. If the originator use
>a key shared only with the MLA, then the MLA will need to decrypt the
>message and rencrypt the message for the list recipients."
>
>
> > Page 5, Figure 1, the picture needs a bit of patching so that the lines
> > connecting the GL to the members actually align.
>
>Fixed
>
> > Page 5, 2nd para, 2nd sentence, the "'" seems to be damaged.  You
probably
> > edited the document in an editor which does not always put out pure 
> ASCII. In
> > particular, your "'" comes out as a combined AE character.  Some of the 
> double
> > quotes (") come out as an "o" with a circumflex over it.  You might want
to
> > patch these throughout the document before final submission.
>
>As it turns out I had "smart quotes" turned on which ended up being the
>dumb thing to do. I'll scrub the document and make they get fixed.
>
> > Page 5, 2nd para, 4 sentence, change "setup" to "set up".
>
>Fixed
>
> > Page 5, Section 3, para 1, 4th sentence, change "setup" to "set 
> up".  Also fix
> > the "'"s in this paragraph.
>
>Fixed
>
> > Page 8, 1st para, last sentence, here's an example of the "o with 
> circumflex"
> > problem.
>
>Fixed
>
> > Page 9, GLInfo, why did you include both the glName and glAddress here 
> but not
> > in GLAddMember, for example?
>
>Well I figured it would be helpful as the name does not always provide
>enough information to allow you to contact them.  I was also trying
>desperately trying to avoid any issues with name forms.
>
> > Page 9, GLOwnerInfo.glOwnerName, do you wish to note that this name for
is
> > constrained to match that found in the owner's certificate?
>
>I think I meant to move the 2nd sentence in the glOwnerAddress to
>glOwnerName.
>
> > Page 9, GLOwnerInfo.glOwnerAddress, do you wish to constrain the 
> GeneralName
> > form used?
>
>No :) We're trying to be application independent.
>
> > Page 9, Certificates, would it be useful to include CRLs as well (ala
> > CMC/CMS)?
>
>You would include the CRLs in the outer CMS envelope.  Or they could put
>in the CRLDP.  I guess we were just trying to keep it small.
>
> > Page 10, 6th bullet, this paragraph does not make sense.  It looks like
you
> > did a cut-and-paste from later in the document.  In particular, you 
> talk about
> > "that member" -- which member?  Also, adding another GLO is not 
> performed by
> > this control so why have a discussion about adding another GLO 
> here?  Plus an
> > encryption certificate seems inappropriate since a GLO does not need to 
> be a
> > member of GL, right?
>
>"that member" should have been "that GLO".  The 2nd to last sentence
>shouldn't be there as you are correct that this attribute no longer can
>be used to add new GLOs. I ended up replacing the last two sentences
>with: "It will be used to encrypt responses for the GLO."
>
> > Page 10, 10th bullet (Unmanaged), change "they are" to "it is".
>
>Fixed
>
> > Page 10, 11th bullet (Managed), change "they are" to "it is".
>
>Fixed
>
> > Page 11, 1st bullet (Closed), change "they are" to "it is".
>
>Fixed
>
> > Page 11, 4th bullet (recipientsNotMutuallyAware), change "to not be" to 
> "not
> > to be".
>
>FIxed
>
> > Page 13, certificates.aC, it seems odd to include attribute certificates
to
> > modify an encryption certificate when extensions in the encryption 
> certificate
> > might be more appropriate.  This argument is academic -- I do not have
an
> > example of needing this functionality either way.
>
>No action required :)  I'm not trying to be sneaky - basically since we
>used CertificateSet from CMS it's a field that I had to describe.
>
> > Page 14, section 3.1.4, GLDeleteMember.glMemberToDelete, it is not 
> apparent if
> > this is supposed to match the GL member's name or address (GeneralName 
> being
> > sufficiently ambiguous).  This would be a good place to note which one.
>
>To be honest I think it doesn't matter which one gets put there.  When a
>person is added to the GL both the address and name had to be included.
>So when you delete a member either can be used. I did modify the
>sentence to say it could either be the name or address.
>
> > Page 14, metadiscussion, overall issue: there seems to be a lot of 
> compositing
> > of controls, such as changing list attributes while rekeying the list.
I
> > think these functions should be decomposed into separate controls.
>
>I guess my idea was to keep it simple.  Since almost all of the fields
>are optional you only need to include the ones that you want to change.
>I think it's just an organizational thing.
>
> > Page 15, 2nd bullet, what does "outstanding" mean?
>
>Outstanding refers to keys that were predistributed.  When you set up
>the GLO you can have X number of keys distributed (where X is specified
>in generationCounter).  It shouldn't be in the glNewKeyAttributes
>bullet, but it should be in glRekeyAllGLKeys bullet.
>
> > Page 16, section 3.1.8, last sentence, change "included" to "placed".  I
> > believe GLKCompromise is complete and not partial (inclusive).
>
>Fixed
>
> > Page 19, 3rd bullet, which name form?  Also, place a period at the end 
> of this
> > sentence.
>
>The GLA is only going to have the name form that GLO or GL member
>provided.  The GLO is going to have the one that the either the GL
>member provided or one that he found in the directory.  I'm not sure
>where it's ambiguous.
>
> > Page 19, metadiscussion, general comment: use of GeneralName should
specify
> > the preferred form.
>
>The one they used to sign up with.
>
> > Page 20, last paragraph, change "FALSE" to "TRUE".  This seems to be a 
> problem
> > throughout the document.  As I understand it, the attribute
> > "recipientsNotMutually- Aware" would be set to TRUE when it is desired
that
> > the recipients are not aware of each other, and thus a separate glKey 
> message
> > should be generated for each recipient.
>
>Fixed
>
> > Page 20, last paragraph, last sentence, insert a comma between 
> "recipient" and
> > "you".
>
>Fixed
>
> > Page 21, 2nd bullet, change "FALSE" to "TRUE".
>
>Fixed
>
> > Page 21, 5th fullet, change "FALSE" to "TRUE".
>
>Fixed
>
> > Page 24, section 3.2.3, 2nd para, 1st sentence, insert a space between
> > "cMCStatusInfoEx" and "and".  They ran together.
>
>Fixed
>
> > Page 24, section 3.2.3, 2nd para, 1st sentence, change "FALSE" to
"TRUE".
>
>Fixed
>
> > Page 24, overall problem, change "cMCStatusInfoEx" to "cMCStatusInfoExt"
> > throughout the document.  Both forms appear in the draft on the IETF 
> servers,
> > however, the "Ex" form only appears twice and does not appear to be the
> > canonical form (i.e., in the ASN.1).
>
>Global replace of InfoEx with InfoExt
>
> > Page 28, section 3.2.4.3, 2nd para, 1st sentence, change "aggratates" to
> > "aggragates".
>
>Fixed
>
> > Page 30, 2.b, immediately following the number/letter indicator is a "u 
> with
> > circumflex". I presume this is supposed to be a "-", but may be your
word
> > processors substitution for an em-dash or en-dash.
>
>Fixed.




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCGsYj18255 for ietf-smime-bks; Wed, 12 Dec 2001 08:54:34 -0800 (PST)
Received: from tweety (243-198-131-12.bellhead.com [12.131.198.243]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCGsW218249 for <[e-mail]>; Wed, 12 Dec 2001 08:54:32 -0800 (PST)
Received: from [12.131.198.243] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 12 Dec 2001 11:43:38 -0500
Message-ID: <[e-mail]>
Date: Wed, 12 Dec 2001 10:42:31 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: Re: Input desired on symkeydist?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are some editorial comments on the symkeydist-06 draft.  I'll defer
to Russ as to how to handle these.

"Yee, Peter" wrote:

> Page 3, para 2, 2nd sentence, change "ReipientInfo" to "RecipientInfo".

Fixed

> Page 3, para 2, metadiscussion, is it appropriate to jump in with ktri and
> kari this early in the document?

I thought it was a good lead in to explain the difference between the
ktri | kari and kekri.  I figured most people from the S/MIME group
would be fully aware of the other two choices but maybe not the kekri.

> Page 3, para 2, last sentence, change (twice) "their" to "its".

Fixed

> Page 4, para 1, you state that the security provided "is only as good as the
> sum...".  I content that it "is only as good as the weakest protection
> mechanism employed."  The KEK only has to be retrieved from the holder with
> the weakest protections to be compromised.

We're basically trying to say it's the sum of weakest people on the
list. Unfortunately, right now the english is escaping me.

> Page 4, section 1.2, 1st sentence, change "Light Weight" to "Lightweight".

Fixed

> Page 4, section 1.2, 2nd sentence, change "any one" to "anyone".

Fixed

> Page 5, scenario 2, are the "S" keys the same.  I don't believe so, in which
> case I would label one "S1" and the other "S2".

Actually I was thinking they were, but they don't have to be the same.
They could be different.  Is it worth adding: 
"The key used by the originator could either be a key shared amongst all
recipients or just between the member and the MLA. If the originator use
a key shared only with the MLA, then the MLA will need to decrypt the
message and rencrypt the message for the list recipients."


> Page 5, Figure 1, the picture needs a bit of patching so that the lines
> connecting the GL to the members actually align.

Fixed

> Page 5, 2nd para, 2nd sentence, the "'" seems to be damaged.  You probably
> edited the document in an editor which does not always put out pure ASCII. In
> particular, your "'" comes out as a combined AE character.  Some of the double
> quotes (") come out as an "o" with a circumflex over it.  You might want to
> patch these throughout the document before final submission.

As it turns out I had "smart quotes" turned on which ended up being the
dumb thing to do. I'll scrub the document and make they get fixed.

> Page 5, 2nd para, 4 sentence, change "setup" to "set up".

Fixed

> Page 5, Section 3, para 1, 4th sentence, change "setup" to "set up".  Also fix
> the "'"s in this paragraph.

Fixed

> Page 8, 1st para, last sentence, here's an example of the "o with circumflex"
> problem.

Fixed

> Page 9, GLInfo, why did you include both the glName and glAddress here but not
> in GLAddMember, for example?

Well I figured it would be helpful as the name does not always provide
enough information to allow you to contact them.  I was also trying
desperately trying to avoid any issues with name forms.

> Page 9, GLOwnerInfo.glOwnerName, do you wish to note that this name for is
> constrained to match that found in the owner's certificate?

I think I meant to move the 2nd sentence in the glOwnerAddress to
glOwnerName.

> Page 9, GLOwnerInfo.glOwnerAddress, do you wish to constrain the GeneralName
> form used?

No :) We're trying to be application independent.

> Page 9, Certificates, would it be useful to include CRLs as well (ala
> CMC/CMS)?

You would include the CRLs in the outer CMS envelope.  Or they could put
in the CRLDP.  I guess we were just trying to keep it small.

> Page 10, 6th bullet, this paragraph does not make sense.  It looks like you
> did a cut-and-paste from later in the document.  In particular, you talk about
> "that member" -- which member?  Also, adding another GLO is not performed by
> this control so why have a discussion about adding another GLO here?  Plus an
> encryption certificate seems inappropriate since a GLO does not need to be a
> member of GL, right?

"that member" should have been "that GLO".  The 2nd to last sentence
shouldn't be there as you are correct that this attribute no longer can
be used to add new GLOs. I ended up replacing the last two sentences
with: "It will be used to encrypt responses for the GLO."

> Page 10, 10th bullet (Unmanaged), change "they are" to "it is".

Fixed

> Page 10, 11th bullet (Managed), change "they are" to "it is".

Fixed

> Page 11, 1st bullet (Closed), change "they are" to "it is".

Fixed

> Page 11, 4th bullet (recipientsNotMutuallyAware), change "to not be" to "not
> to be".

FIxed

> Page 13, certificates.aC, it seems odd to include attribute certificates to
> modify an encryption certificate when extensions in the encryption certificate
> might be more appropriate.  This argument is academic -- I do not have an
> example of needing this functionality either way.

No action required :)  I'm not trying to be sneaky - basically since we
used CertificateSet from CMS it's a field that I had to describe.

> Page 14, section 3.1.4, GLDeleteMember.glMemberToDelete, it is not apparent if
> this is supposed to match the GL member's name or address (GeneralName being
> sufficiently ambiguous).  This would be a good place to note which one.

To be honest I think it doesn't matter which one gets put there.  When a
person is added to the GL both the address and name had to be included. 
So when you delete a member either can be used. I did modify the
sentence to say it could either be the name or address.

> Page 14, metadiscussion, overall issue: there seems to be a lot of compositing
> of controls, such as changing list attributes while rekeying the list.  I
> think these functions should be decomposed into separate controls.

I guess my idea was to keep it simple.  Since almost all of the fields
are optional you only need to include the ones that you want to change. 
I think it's just an organizational thing.

> Page 15, 2nd bullet, what does "outstanding" mean?

Outstanding refers to keys that were predistributed.  When you set up
the GLO you can have X number of keys distributed (where X is specified
in generationCounter).  It shouldn't be in the glNewKeyAttributes
bullet, but it should be in glRekeyAllGLKeys bullet.

> Page 16, section 3.1.8, last sentence, change "included" to "placed".  I
> believe GLKCompromise is complete and not partial (inclusive).

Fixed

> Page 19, 3rd bullet, which name form?  Also, place a period at the end of this
> sentence.

The GLA is only going to have the name form that GLO or GL member
provided.  The GLO is going to have the one that the either the GL
member provided or one that he found in the directory.  I'm not sure
where it's ambiguous.

> Page 19, metadiscussion, general comment: use of GeneralName should specify
> the preferred form.

The one they used to sign up with.

> Page 20, last paragraph, change "FALSE" to "TRUE".  This seems to be a problem
> throughout the document.  As I understand it, the attribute
> "recipientsNotMutually- Aware" would be set to TRUE when it is desired that
> the recipients are not aware of each other, and thus a separate glKey message
> should be generated for each recipient.

Fixed

> Page 20, last paragraph, last sentence, insert a comma between "recipient" and
> "you".

Fixed

> Page 21, 2nd bullet, change "FALSE" to "TRUE".

Fixed

> Page 21, 5th fullet, change "FALSE" to "TRUE".

Fixed

> Page 24, section 3.2.3, 2nd para, 1st sentence, insert a space between
> "cMCStatusInfoEx" and "and".  They ran together.

Fixed

> Page 24, section 3.2.3, 2nd para, 1st sentence, change "FALSE" to "TRUE".

Fixed

> Page 24, overall problem, change "cMCStatusInfoEx" to "cMCStatusInfoExt"
> throughout the document.  Both forms appear in the draft on the IETF servers,
> however, the "Ex" form only appears twice and does not appear to be the
> canonical form (i.e., in the ASN.1).

Global replace of InfoEx with InfoExt

> Page 28, section 3.2.4.3, 2nd para, 1st sentence, change "aggratates" to
> "aggragates".

Fixed

> Page 30, 2.b, immediately following the number/letter indicator is a "u with
> circumflex". I presume this is supposed to be a "-", but may be your word
> processors substitution for an em-dash or en-dash.

Fixed.





Received: by above.proper.com (8.11.6/8.11.3) id fBC0vMw02822 for ietf-smime-bks; Tue, 11 Dec 2001 16:57:22 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBC0vK202818 for <[e-mail]>; Tue, 11 Dec 2001 16:57:20 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Dec 2001 00:57:15 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA19236 for <[e-mail]>; Tue, 11 Dec 2001 19:57:16 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBC0vFd22445 for <[e-mail]>; Tue, 11 Dec 2001 19:57:15 -0500 (EST)
Received: by EXNA00 with Internet Mail Service (5.5.2653.19) id <YQMZCC97>; Tue, 11 Dec 2001 19:57:13 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.26]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YQMZCC96; Tue, 11 Dec 2001 19:57:10 -0500
From: "Housley, Russ" <[e-mail]>
To: Christian Geuer-Pollmann <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 11 Dec 2001 19:42:01 -0500
Subject: Re: Typo in example from draft-ietf-smime-key-wrap-01.txt
In-Reply-To: <2988712075.1008011059@pinkpanther>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Christian:

Thanks for catching this typo.  This document is about to become an RFC, I 
will make sure the RFC Editor fixes it prior to publication.

Russ


At 07:04 PM 12/10/2001 +0100, Christian Geuer-Pollmann wrote:
>Hi Russell,
>hi xenc implementors who wanna implement the required KeyWrap 
>http://www.w3.org/2001/04/xmlenc#kw-tripledes :
>
>
>In Section 3.4 of [1], the variable TEMP1 has a twisted HEX value: 3b97 
>should be 973b.
>
>3.4  Triple-DES Key Wrap Example
>
>WRONG !!!!!
>   TEMP1:   cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 3b97 7a79 60f6
>            a44d cc5f 729d 8449
>
>RIGHT:
>   TEMP1:   cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6
>            a44d cc5f 729d 8449
>
>
>Thanks,
>Christian
>
>
>[1] Triple-DES and RC2 Key Wrapping
>    http://www.ietf.org/internet-drafts/draft-ietf-smime-key-wrap-01.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6JZBT03283 for ietf-smime-bks; Thu, 6 Dec 2001 11:35:11 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6JZ8203279 for <[e-mail]>; Thu, 6 Dec 2001 11:35:09 -0800 (PST)
Received: from revelation ([12.230.197.121]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011206193501.PDVC4213.rwcrmhc52.attbi.com@revelation>; Thu, 6 Dec 2001 19:35:01 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC2630-bis comment
Date: Thu, 6 Dec 2001 11:34:59 -0800
Message-ID: <000e01c17e8d$17e92b50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

No I did not agree with that.   SignedAttributes is

SignedAttributes ::= SET OF SignedAttribute

SignedAttribute ::= SET OF Attribute

Attribute ::= SEQUENCE {
   attrType OBJECT IDENTIFIER,
   attrValue  SET OF ANY
}

If I do a re-encode of SignedAttributes as part of the signature
creation/verification process, and I re-encode this as a DER encoding,
all three SETs will automatically be sorted during the encode process no
matter what their order is in the data I pass in.  The thing that cannot
be DER encoded during this process is the ANY values inside of the
attrValue SET.  This is what I don't know how to decode/re-encode during
the process.  With the way that I have setup my encode of the SignedInfo
structure, I don't encode the attrValue SET using DER, but using BER
rules (i.e. no sort operation).  If John or anybody else decodes the
entire SignedInfo structure, re-encodes the SignedAttributes section
they will get the correct sequence of bytes to hash (assuming that the
ANYs are correctly DER encoded).

As the language currently stands, I need to encode SignedAttribute using
the DER encoding rules and then can encode SignedAttributes using the
BER encoding rules.  This does not make sense to me.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Thursday, December 06, 2001 6:00 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: RFC2630-bis comment
> 
> 
> 
> Jim:
> 
> So, you just agreed that the SET must be DER encoded.  I 
> think that is what 
> the document says.  What am I missing?
> 
> Russ
> 
> At 08:21 PM 12/5/2001 -0800, Jim Schaad wrote:
> >Russ,
> >
> >While it is true that the order cannot be known after the 
> decode, if you
> >re-encode the set of attributes the correct order will be obtained.
> >
> >jim
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Housley, Russ
> > > Sent: Wednesday, December 05, 2001 3:15 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: RFC2630-bis comment
> > >
> > >
> > >
> > > Jim:
> > >
> > > My understanding is that ASN.1 tool sets are not guaranteed
> > > to preserve the
> > > order with a SET on decode.  So, if the attribute has more
> > > than one value,
> > > then the values must be places in sort order to ensure that
> > > the originator
> > > and the recipient will compute the same hash value.  If 
> the attribute
> > > values can be in an arbitrary ordering, a recipient cannot
> > > know the order
> > > used by the originator.
> > >
> > > Russ
> > >
> > > At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:
> > > >Russ,
> > > >
> > > >I believe that the requirement in section 5.3 about DER 
> encoding of
> > > >SignedAttributes is too restrictive.  The current 
> statement is "Each
> > > >SignedAttribute in the SET MUST be DER encoded."  I 
> believe that the
> > > >intended statement is really "Each AttributeValue in the
> > > >SignedAttributes SET MUST be DER encoded."
> > > >
> > > >Here is my problem.  Assume that I have an attribute FOO
> > > with 3 values.
> > > >If I do the encode of the entire SignerInfo object in one
> > > shot, then I
> > > >cannot cause the sort of the the attribute values 
> without doing a DER
> > > >encoding of the SignerInfo object.  It's easy to correctly
> > > DER encode an
> > > >attribute if the attribute values are correctly DER 
> encoded, and this
> > > >deals with the potential problem of a third party having to
> > > decode and
> > > >re-encode the values.
> > > >
> > > >Please make this change as it continues to statisfy the 
> requirement
> > > >behind the added statement, but imposes the smallest
> > > requirement on the
> > > >implementors.
> > > >
> > > >Jim
> > >
> 



Received: by above.proper.com (8.11.6/8.11.3) id fB6F38G13753 for ietf-smime-bks; Thu, 6 Dec 2001 07:03:08 -0800 (PST)
Received: from wfhqex03.gfgsi.com ([67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6F37213749 for <[e-mail]>; Thu, 6 Dec 2001 07:03:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: RFC2630-bis comment
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Thu, 6 Dec 2001 10:04:38 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC2630-bis comment
Thread-Index: AcF+Fg2wqyAh9dgXR0uEvmQvZGTifgAULBiQ
From: "Pawling, John" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fB6F38213750
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

But that is only true if the attribute values were DER-encoded in the
correct order by the signer as part of the process of calculating the
hash value.  Therefore, I agree with Russ that the RFC2630 requirement
that "Each SignedAttribute in the SET MUST be DER encoded." should not
be changed.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Wednesday, December 05, 2001 11:22 PM
To: 'Housley, Russ'; [e-mail]
Cc: [e-mail]
Subject: RE: RFC2630-bis comment



Russ,

While it is true that the order cannot be known after the decode, if you
re-encode the set of attributes the correct order will be obtained.  

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Wednesday, December 05, 2001 3:15 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: RFC2630-bis comment
> 
> 
> 
> Jim:
> 
> My understanding is that ASN.1 tool sets are not guaranteed 
> to preserve the 
> order with a SET on decode.  So, if the attribute has more 
> than one value, 
> then the values must be places in sort order to ensure that 
> the originator 
> and the recipient will compute the same hash value.  If the attribute 
> values can be in an arbitrary ordering, a recipient cannot 
> know the order 
> used by the originator.
> 
> Russ
> 
> At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:
> >Russ,
> >
> >I believe that the requirement in section 5.3 about DER encoding of
> >SignedAttributes is too restrictive.  The current statement is "Each
> >SignedAttribute in the SET MUST be DER encoded."  I believe that the
> >intended statement is really "Each AttributeValue in the
> >SignedAttributes SET MUST be DER encoded."
> >
> >Here is my problem.  Assume that I have an attribute FOO 
> with 3 values.
> >If I do the encode of the entire SignerInfo object in one 
> shot, then I
> >cannot cause the sort of the the attribute values without doing a DER
> >encoding of the SignerInfo object.  It's easy to correctly 
> DER encode an
> >attribute if the attribute values are correctly DER encoded, and this
> >deals with the potential problem of a third party having to 
> decode and
> >re-encode the values.
> >
> >Please make this change as it continues to statisfy the requirement
> >behind the added statement, but imposes the smallest 
> requirement on the
> >implementors.
> >
> >Jim
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6E3K409778 for ietf-smime-bks; Thu, 6 Dec 2001 06:03:20 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB6E3I209774 for <[e-mail]>; Thu, 6 Dec 2001 06:03:18 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 6 Dec 2001 14:03:13 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA18734 for <[e-mail]>; Thu, 6 Dec 2001 09:03:18 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB6E3HK12891 for <[e-mail]>; Thu, 6 Dec 2001 09:03:17 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YH83DQ2D>; Thu, 6 Dec 2001 09:03:17 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YH83DQ2C; Thu, 6 Dec 2001 09:03:15 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Dec 2001 08:59:42 -0500
Subject: RE: RFC2630-bis comment
In-Reply-To: <000501c17e0d$7e38a280$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

So, you just agreed that the SET must be DER encoded.  I think that is what 
the document says.  What am I missing?

Russ

At 08:21 PM 12/5/2001 -0800, Jim Schaad wrote:
>Russ,
>
>While it is true that the order cannot be known after the decode, if you
>re-encode the set of attributes the correct order will be obtained.
>
>jim
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Housley, Russ
> > Sent: Wednesday, December 05, 2001 3:15 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: RFC2630-bis comment
> >
> >
> >
> > Jim:
> >
> > My understanding is that ASN.1 tool sets are not guaranteed
> > to preserve the
> > order with a SET on decode.  So, if the attribute has more
> > than one value,
> > then the values must be places in sort order to ensure that
> > the originator
> > and the recipient will compute the same hash value.  If the attribute
> > values can be in an arbitrary ordering, a recipient cannot
> > know the order
> > used by the originator.
> >
> > Russ
> >
> > At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:
> > >Russ,
> > >
> > >I believe that the requirement in section 5.3 about DER encoding of
> > >SignedAttributes is too restrictive.  The current statement is "Each
> > >SignedAttribute in the SET MUST be DER encoded."  I believe that the
> > >intended statement is really "Each AttributeValue in the
> > >SignedAttributes SET MUST be DER encoded."
> > >
> > >Here is my problem.  Assume that I have an attribute FOO
> > with 3 values.
> > >If I do the encode of the entire SignerInfo object in one
> > shot, then I
> > >cannot cause the sort of the the attribute values without doing a DER
> > >encoding of the SignerInfo object.  It's easy to correctly
> > DER encode an
> > >attribute if the attribute values are correctly DER encoded, and this
> > >deals with the potential problem of a third party having to
> > decode and
> > >re-encode the values.
> > >
> > >Please make this change as it continues to statisfy the requirement
> > >behind the added statement, but imposes the smallest
> > requirement on the
> > >implementors.
> > >
> > >Jim
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB64LgO19452 for ietf-smime-bks; Wed, 5 Dec 2001 20:21:42 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB64Ld219447 for <[e-mail]>; Wed, 5 Dec 2001 20:21:40 -0800 (PST)
Received: from revelation ([12.230.197.121]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011206042136.MGEJ24045.rwcrmhc53.attbi.com@revelation>; Thu, 6 Dec 2001 04:21:36 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC2630-bis comment
Date: Wed, 5 Dec 2001 20:21:35 -0800
Message-ID: <000501c17e0d$7e38a280$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

While it is true that the order cannot be known after the decode, if you
re-encode the set of attributes the correct order will be obtained.  

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Wednesday, December 05, 2001 3:15 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: RFC2630-bis comment
> 
> 
> 
> Jim:
> 
> My understanding is that ASN.1 tool sets are not guaranteed 
> to preserve the 
> order with a SET on decode.  So, if the attribute has more 
> than one value, 
> then the values must be places in sort order to ensure that 
> the originator 
> and the recipient will compute the same hash value.  If the attribute 
> values can be in an arbitrary ordering, a recipient cannot 
> know the order 
> used by the originator.
> 
> Russ
> 
> At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:
> >Russ,
> >
> >I believe that the requirement in section 5.3 about DER encoding of
> >SignedAttributes is too restrictive.  The current statement is "Each
> >SignedAttribute in the SET MUST be DER encoded."  I believe that the
> >intended statement is really "Each AttributeValue in the
> >SignedAttributes SET MUST be DER encoded."
> >
> >Here is my problem.  Assume that I have an attribute FOO 
> with 3 values.
> >If I do the encode of the entire SignerInfo object in one 
> shot, then I
> >cannot cause the sort of the the attribute values without doing a DER
> >encoding of the SignerInfo object.  It's easy to correctly 
> DER encode an
> >attribute if the attribute values are correctly DER encoded, and this
> >deals with the potential problem of a third party having to 
> decode and
> >re-encode the values.
> >
> >Please make this change as it continues to statisfy the requirement
> >behind the added statement, but imposes the smallest 
> requirement on the
> >implementors.
> >
> >Jim
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5NEmd03419 for ietf-smime-bks; Wed, 5 Dec 2001 15:14:48 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB5NEk203415 for <[e-mail]>; Wed, 5 Dec 2001 15:14:46 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Dec 2001 23:14:43 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA13285 for <[e-mail]>; Wed, 5 Dec 2001 18:14:48 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB5NEjo00521 for <[e-mail]>; Wed, 5 Dec 2001 18:14:45 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YH83DL1G>; Wed, 5 Dec 2001 18:14:45 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YH83DL1D; Wed, 5 Dec 2001 18:14:43 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 05 Dec 2001 18:14:31 -0500
Subject: Re: RFC2630-bis comment
In-Reply-To: <000001c17dd6$c1d416a0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

My understanding is that ASN.1 tool sets are not guaranteed to preserve the 
order with a SET on decode.  So, if the attribute has more than one value, 
then the values must be places in sort order to ensure that the originator 
and the recipient will compute the same hash value.  If the attribute 
values can be in an arbitrary ordering, a recipient cannot know the order 
used by the originator.

Russ

At 01:49 PM 12/5/2001 -0800, Jim Schaad wrote:
>Russ,
>
>I believe that the requirement in section 5.3 about DER encoding of
>SignedAttributes is too restrictive.  The current statement is "Each
>SignedAttribute in the SET MUST be DER encoded."  I believe that the
>intended statement is really "Each AttributeValue in the
>SignedAttributes SET MUST be DER encoded."
>
>Here is my problem.  Assume that I have an attribute FOO with 3 values.
>If I do the encode of the entire SignerInfo object in one shot, then I
>cannot cause the sort of the the attribute values without doing a DER
>encoding of the SignerInfo object.  It's easy to correctly DER encode an
>attribute if the attribute values are correctly DER encoded, and this
>deals with the potential problem of a third party having to decode and
>re-encode the values.
>
>Please make this change as it continues to statisfy the requirement
>behind the added statement, but imposes the smallest requirement on the
>implementors.
>
>Jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5LoDH28384 for ietf-smime-bks; Wed, 5 Dec 2001 13:50:13 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Lo7228372 for <[e-mail]>; Wed, 5 Dec 2001 13:50:08 -0800 (PST)
Received: from revelation ([12.230.197.121]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011205214947.VFCS1879.rwcrmhc52.attbi.com@revelation>; Wed, 5 Dec 2001 21:49:47 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Subject: RFC2630-bis comment
Date: Wed, 5 Dec 2001 13:49:46 -0800
Message-ID: <000001c17dd6$c1d416a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I believe that the requirement in section 5.3 about DER encoding of
SignedAttributes is too restrictive.  The current statement is "Each
SignedAttribute in the SET MUST be DER encoded."  I believe that the
intended statement is really "Each AttributeValue in the
SignedAttributes SET MUST be DER encoded."

Here is my problem.  Assume that I have an attribute FOO with 3 values.
If I do the encode of the entire SignerInfo object in one shot, then I
cannot cause the sort of the the attribute values without doing a DER
encoding of the SignerInfo object.  It's easy to correctly DER encode an
attribute if the attribute values are correctly DER encoded, and this
deals with the potential problem of a third party having to decode and
re-encode the values.

Please make this change as it continues to statisfy the requirement
behind the added statement, but imposes the smallest requirement on the
implementors.

Jim




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB4HVNN10999 for ietf-smime-bks; Tue, 4 Dec 2001 09:31:23 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB4HVL210995 for <[e-mail]>; Tue, 4 Dec 2001 09:31:21 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Dec 2001 17:31:18 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA10801 for <[e-mail]>; Tue, 4 Dec 2001 12:31:22 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB4HVDv08154 for <[e-mail]>; Tue, 4 Dec 2001 12:31:14 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YH83C29A>; Tue, 4 Dec 2001 12:31:10 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.127]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YH83C2WZ; Tue, 4 Dec 2001 12:28:35 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 04 Dec 2001 12:28:30 -0500
Subject: S/MIME WG Agenda for 52nd IETF
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

S/MIME Mail Security WG Agenda

Introductions				Russ Housley
Working Group Status			Russ Housley
CMS Update Status			Russ Housley
Interoperability Matrix 			Jim Schaad
CMS and ESS Examples 		Paul Hoffman
AES and RSA-OAEP			Jim Schaad
Symmetric Key Distribution		Sean Turner
Intended Recipient Attribute		Russ Housley & Jim Schaad
Policy Requirements for TSAs		Denis Pinkas
Wrap up				Russ Housley


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3KDWu15253 for ietf-smime-bks; Mon, 3 Dec 2001 12:13:32 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB3KDT215247 for <[e-mail]>; Mon, 3 Dec 2001 12:13:29 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Dec 2001 20:13:27 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA13564; Mon, 3 Dec 2001 15:13:31 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB3KDL803387; Mon, 3 Dec 2001 15:13:22 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YFW8S70G>; Mon, 3 Dec 2001 14:59:42 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.87 [10.3.1.87]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YFW8S6XJ; Mon, 3 Dec 2001 14:45:27 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 03 Dec 2001 14:18:35 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-aes-alg-03.txt
In-Reply-To: <A7896A2B763AD511B27C00AA00DD93713CD1DA@NIAGARA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francois:

>I have the following comments on this updated Internet Draft:
>
>a.  Section 2.3.1 indicates that Generation of the an AES key used in doing
>AES-KeyWrap is done using the method in [DH] with the following
>modifications: The Hash function H will be [SHA-256] rather than SHA-1.  As
>you know, RFC2631 defines one Key Derivation Function (KDF), which is
>derived from one of the two KDFs defined under ANSI X9.42.  However, NIST
>recently suggested a new standardized KDF for both ANSI X9.42 and X9.63 in
>its Key Establishment Schemes document presented at its second Key
>Management Workshop on November 1-2.  Since you are already questioning if
>you should change the OID for this KDF because you are mandating SHA-256 not
>SHA-1, shouldn't S/MIME, NIST and ANSI take this opportunity to standardize
>on one common algorithm for this KDF?

Jim and I had an e-mail exchange with Paul Timmel on this subject.  We plan 
to stick with SHA-1.

>b.  Section 2.3.2 is about the AES CEK wrap process, shouldn't it be more
>general than just wrapping an AES key in another AES key similarly to the
>recently approved <draft-ietf-smime-key-wrap-01.txt>?  If yes, the last
>sentence of this section indicates that if different lengths are supported,
>the KEK MUST be of equal or greater length then the CEK.  I would disagree
>with this mandatory requirement if other types of keys could be wrapped an
>AES key.  Take for example Triple DES with three keys (i.e. 192 bits), which
>has only an effective strength of 112 bits, could securely be wrapped with a
>KEK of 128 bits instead of 192 bits.  This last comment also applies to
>Section 6, which indicates that when wrapping a content-encryption key with
>a key-encryption key, the key-encryption key should always be at least the
>same length as the content-encryption key.

I do not think that this is a general mechanism.  The one in 
draft-ietf-smime-key-wrap-01 certainly is not.  The analysis of the 
algorithms in draft-ietf-smime-key-wrap-01 was not done for the general 
cases.  NIST has said that this algorithm is appropriate for wrapping one 
AES key with another, and that is how we plan to use it.

I do not see any reason to mix algorithms.

>Feel free to distribute these comments and your response on the mailing list
>since I am not currently a member of the S/MIME list, but only monitor its
>status on the web site.

Russ