Subject: Re: MIXER Impact on CMS-X400

From: Jim Craigie <[email-masked]>
Date: Wed, 30 Jan 2002 14:11:36 +0000

On 27 December 2001 Chris Bonatti wrote:
> 
>    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.

Chris,

Sorry that it has taken so long for me to find the time to reply.

As you note in your message, RFC2156 explicitly limits its scope to the X.420 Interpersonal Messaging System, and "not to wider application of X.400".  Your text for inclusion in the drafts should state this.

Since RFC2156 does not specify how to gateway X.400 content types other than IPMS, it is not sufficient to say "translation must be limited to the envelope fields only " - unless you spell out the detail implementors will not produce consistent behaviour. Your drafts (or an addendum to MIXER) need to state precisely which parts of RFC2156 are applicable when gatewaying of the content types defined in x400transport and x400wrap is to be performed.

X400wrap fails to mention that when the objects it defines are transported over SMTP transport there will of necessity for conformance to RFC 2822 be a vestigial Header. This will comprise at a minimum the mandatory Header fields specified in RFC 2822: "From:" and "Date:". If it is intended that these fields (which duplicate semantics already contained within the X.400 content within the wrapped object, but are not derived from them) are to be ignored on reception then this must be stated explicitly. If this is the case, then the values in these fields on origination can be arbitrary. Given this additional specification, gatewaying of the x400wrap content is straightforward, but does need to be specified.

Neither your drafts (quite reasonably) nor any other RFC that I can find specifies how an X.400 content (without CMS protection) can be conveyed by SMTP transport. For completeness, could this be included in x400wrap? I propose:

Content-Type: application/x400-content; content-type = 1*DIGIT *( "." 1*DIGIT)
where the content-type parmeter value is either a single integer (for a built-in content-type) or an OID in dotted notation (for an extended content-type).

Either your drafts or a separate addendum to MIXER can then specify simple gatewaying rules at the message transport level for any X.400 content-type, defaulting to the above for a content-type for which no other mapping is defined.

Having reviewed your drafts again, I have several additional comments.

X400wrap also omits mention of two other documents that it affects: RFC2632 and STANAG 4406.

X400wrap omits mention of changes to requirements on Certificates. It should state that for this content the following wording replaces the second and third paragraphs in section 3 of RFC2632:

   Receiving agents MUST recognize X.400 addresses in the subjectAltName field.

   Sending agents SHOULD make the address in the Originator or Authorising User
   heading field in a wrapped mail message match an X.400 address in the signer's
   certificate. Receiving agents MUST check that the address in the Originator
   or Authorising User heading field of a mail message matches an X.400 address
   in the signer's certificate, if X.400 addresses are present in the
   certificate. A receiving agent SHOULD provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   display a message that shows the recipient the addresses in the
   certificate or other certificate details.

The combination of X400wrap and X400transport should address compatability with the PCT format defined in STANAG 4406 version 3. In particular, PCT defines both a wrapped and a "clear-signed" encoding of its signature. The latter is particularly useful as it allows signatures to be introduced whilst preserving interworking through backwards compatability with systems that do not incorporate support for PCT. PCT has a major asset in that it is an algorithmic mapping between the two encodings: thus a signature generated for one encoding can be mapped in transit into the other encoding preserving the signature of the originator.

Other comments on X400transport:

1. Section 2.2 first sentence:
Replace "a CMS object" by "an entire S/MIME message".
Rationale: CMS protection can be applied to objects which are not S/MIME messages. X.400 message content certainly would not be the preferred (or even an appropriate) approach to transporting e.g. a CMS protected Excel spreadsheet file in an X.400 environment.

2. Section 2.2
I cannot see the purpose of introducing the X.400 content-type for a CMS object covered by an outer MIME wrapper. It seems to me to introduce an option which adds no value, since the MIME wrapper can be added or subtracted as needed (e.g. when gatewaying to SMTP transport) without affecting the CMS object. Options which add no value should be avoided!

3. Section 2.3:
Comment 1 applies here too. In addition, while in theory you could define X.400 content types to make the assertions in the third and fourth sentences true, they are untrue in practice. It would be better to be positive and state that for transporting an entire S/MIME message an X.400 content is more appropriate than an X.400 body-part (except when forwarding). [I agree with your proposal to use X.400 content - currently a sound proposal is spoilt by dubious rationale!]

4. Section 2.5:
The defined mechanism does not seem to supply enough information on the envelope about a wrapped X.400 content. I don't see any way to identify the actual X.400 content-type that is inside, nor do I see how to distinguish signed-x400 from triple-wrapped-x400.

Jim

X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Wed, 30 Jan 2002 14:11:36 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed, 30 Jan 2002 14:11:36 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0057-020130141136-0048]
X400-Content-Type: P2-1988 (22)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Wed, 30 Jan 2002 14:11:36 +0000
X400-Content-Identifier: Re: MIXER Impact
From: Jim Craigie <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
Cc: IETF SMIME WG <[email-masked]>
Subject: Re: MIXER Impact on CMS-X400
Sender: [email-masked]

On 27 December 2001 Chris Bonatti wrote:
> 
>    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.

Chris,

Sorry that it has taken so long for me to find the time to reply.

As you note in your message, RFC2156 explicitly limits its scope to the X.420 Interpersonal Messaging System, and "not to wider application of X.400".  Your text for inclusion in the drafts should state this.

Since RFC2156 does not specify how to gateway X.400 content types other than IPMS, it is not sufficient to say "translation must be limited to the envelope fields only " - unless you spell out the detail implementors will not produce consistent behaviour. Your drafts (or an addendum to MIXER) need to state precisely which parts of RFC2156 are applicable when gatewaying of the content types defined in x400transport and x400wrap is to be performed.

X400wrap fails to mention that when the objects it defines are transported over SMTP transport there will of necessity for conformance to RFC 2822 be a vestigial Header. This will comprise at a minimum the mandatory Header fields specified in RFC 2822: "From:" and "Date:". If it is intended that these fields (which duplicate semantics already contained within the X.400 content within the wrapped object, but are not derived from them) are to be ignored on reception then this must be stated explicitly. If this is the case, then the values in these fields on origination can be arbitrary. Given this additional specification, gatewaying of the x400wrap content is straightforward, but does need to be specified.

Neither your drafts (quite reasonably) nor any other RFC that I can find specifies how an X.400 content (without CMS protection) can be conveyed by SMTP transport. For completeness, could this be included in x400wrap? I propose:

Content-Type: application/x400-content; content-type = 1*DIGIT *( "." 1*DIGIT)
where the content-type parmeter value is either a single integer (for a built-in content-type) or an OID in dotted notation (for an extended content-type).

Either your drafts or a separate addendum to MIXER can then specify simple gatewaying rules at the message transport level for any X.400 content-type, defaulting to the above for a content-type for which no other mapping is defined.

Having reviewed your drafts again, I have several additional comments.

X400wrap also omits mention of two other documents that it affects: RFC2632 and STANAG 4406.

X400wrap omits mention of changes to requirements on Certificates. It should state that for this content the following wording replaces the second and third paragraphs in section 3 of RFC2632:

   Receiving agents MUST recognize X.400 addresses in the subjectAltName field.

   Sending agents SHOULD make the address in the Originator or Authorising User
   heading field in a wrapped mail message match an X.400 address in the signer's
   certificate. Receiving agents MUST check that the address in the Originator
   or Authorising User heading field of a mail message matches an X.400 address
   in the signer's certificate, if X.400 addresses are present in the
   certificate. A receiving agent SHOULD provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   display a message that shows the recipient the addresses in the
   certificate or other certificate details.

The combination of X400wrap and X400transport should address compatability with the PCT format defined in STANAG 4406 version 3. In particular, PCT defines both a wrapped and a "clear-signed" encoding of its signature. The latter is particularly useful as it allows signatures to be introduced whilst preserving interworking through backwards compatability with systems that do not incorporate support for PCT. PCT has a major asset in that it is an algorithmic mapping between the two encodings: thus a signature generated for one encoding can be mapped in transit into the other encoding preserving the signature of the originator.

Other comments on X400transport:

1. Section 2.2 first sentence:
Replace "a CMS object" by "an entire S/MIME message".
Rationale: CMS protection can be applied to objects which are not S/MIME messages. X.400 message content certainly would not be the preferred (or even an appropriate) approach to transporting e.g. a CMS protected Excel spreadsheet file in an X.400 environment.

2. Section 2.2
I cannot see the purpose of introducing the X.400 content-type for a CMS object covered by an outer MIME wrapper. It seems to me to introduce an option which adds no value, since the MIME wrapper can be added or subtracted as needed (e.g. when gatewaying to SMTP transport) without affecting the CMS object. Options which add no value should be avoided!

3. Section 2.3:
Comment 1 applies here too. In addition, while in theory you could define X.400 content types to make the assertions in the third and fourth sentences true, they are untrue in practice. It would be better to be positive and state that for transporting an entire S/MIME message an X.400 content is more appropriate than an X.400 body-part (except when forwarding). [I agree with your proposal to use X.400 content - currently a sound proposal is spoilt by dubious rationale!]

4. Section 2.5:
The defined mechanism does not seem to supply enough information on the envelope about a wrapped X.400 content. I don't see any way to identify the actual X.400 content-type that is inside, nor do I see how to distinguish signed-x400 from triple-wrapped-x400.

Jim

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-07.txt
Date: Fri, 11 Jan 2002 08:57:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-07.txt
	Pages		: 76
	Date		: 10-Jan-02
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-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-symkeydist-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-symkeydist-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="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Subject: RFC 3218 on Preventing the Million Message Attack on CMS
Cc: [email-masked], [email-masked]
Date: Thu, 10 Jan 2002 10:44:02 -0800
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

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

        RFC 3218

        Title:	    Preventing the Million Message Attack on 
                    Cryptographic Message Syntax
        Author(s):  E. Rescorla
        Status:     Informational
	Date:       January 2002
        Mailbox:    [email-masked]
        Pages:      7
        Characters: 16047
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-pkcs1-01.txt

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

This memo describes a strategy for resisting the Million Message
Attack.

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

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

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3218

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

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

--OtherAccess--
--NextPart--

X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Wed,  9 Jan 2002  3:53:44 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed,  9 Jan 2002  3:53:44 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0054-020109035344-0368]
X400-Content-Type: P2-1988 (22)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [email-masked]
Date: Wed,  9 Jan 2002  3:53:44 +0000
X400-Content-Identifier: Re(2): The subje
From: Jim Craigie <[email-masked]>
To: [email-masked]
Subject: Re(2): The subject line leakage problem
Sender: [email-masked]

> 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

I agree with Ned's proposal. However, the indicator that Ned mentions is an absolute requirement. This indicator is the only way to differentiate a message where the whole header is protected, from a message which is forwarding another. In the latter case it is essential that the From field from the outer unprotected header is not supressed, since it indicates who did the forwarding.

There also needs to be a precise specification of merging the protected header with the unprotected header. The From and Date from the protected header must replace those fields in the outer header (since they cannot be removed from the outer unprotected header). But which other header fields in the outer unprotected header are to be replaced, and which fields are be presented as the union of both headers. For example, Received fields should probably be presented as the union of Received fields from both headers (e.g. to allow a message to be signed by a domain gateway without losing the Received fields before signing).

Jim

Date: Wed, 9 Jan 2002 16:41:26 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Dec 2001 Meeting Minutes
Sender: [email-masked]

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

>Here are the draft minutes.  Please post any objects.
>
>[...]
>
>The first issue dealt with the problem of wrapping an HMAC key with a Triple-
>DES, RC2 or AES key.  There is currently no defined method for this operation.

Yes there is.  The PWRI wrap will wrap any key in any other key.  I've been
wrapping HMAC keys for authenticated data for... well, for as long as it's been
around.

Peter.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-compression-07.txt
Date: Tue, 08 Jan 2002 09:01:48 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Compressed Data Content Type for CMS
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-07.txt
	Pages		: 
	Date		: 07-Jan-02
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for compressing data before processing it. Compressing
data before transmission provides a number of advantages including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps such as signing or encryption, and reducing overall message size.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-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-compression-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-compression-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="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

From: "Jim Schaad" <[email-masked]>
Reply-to: [email-masked]
To: [email-masked]
Date: Tue, 08 Jan 2002 21:41:32 +1100
Subject: Dec 2001 Meeting Minutes
Sender: [email-masked]

Here are the draft minutes.  Please post any objects.

Agenda:  Russ covered the agenda for the meeting.  No changes were made.

Working Group Status:  Russ covered the current status of the active documents
in the working group. Current statuses are:
- Password, Triple-DES/RC2 Key Wrap, and Preventing the Million Message Attack
on CMS documents are in RFC Editor 48 hour review.
- Security Label Implementation document is on hold by request of working group
chairman, and hold will be released when the Attribute Certificate Profile is
published.
- Compression, ECC, X400 Wrap, X400 Transport, and Symmetric Key Distribution
drafts are currently with the IESG.
- RFC2630bis and cmsalg are in IESG last call.

New versions of these RFC 2632 and RFC 2633 are needed since RFC2630bis has
removed algorithm requirements. Blake Ramsdell, the editor of these documents,
has recently changed jobs so a delay in updating the documents is expected.
The updated documents will reflect the mandatory to implement algorithm requirements
that were previously debated and accepted:
	Signature Verification:		DSA and RSA (PKCS#1 v1.5)
	Signature Generation:		DSA or RSA (PKCS#1 v1.5)
	One-way Hash Function:	SHA-1
	Key Management:		RSA (PKCS#1 v1.5)
	Encryption:			Triple-DES CBC

Interoperability Matrix: Jim Schaad presented a briefing on the current state
of interoperability testing for the RFC2630bis and cmsalg drafts.  In the core
of the two documents SignedData has 6 items left, EnvelopedData has 10 items
left, SigningTime has 2 items left and HMAC-SHA-1 has 3 items left.

Jim also presented two issues that had arisen during interoperability testing:

The first issue dealt with the problem of wrapping an HMAC key with a Triple-DES,
RC2 or AES key.  There is currently no defined method for this operation.  A
new draft is to be prepared to define a mechanism.

The second issue dealt with DER encoding of SignedAttributes within the SignerInfo
structure. Three alternatives were presented for a straw poll:  1) SignedAttributes
must be DER encoded, 2) Attribute must be DER encoded, 3) AttributeValue must
be DER encoded.  Option 1 was the unanimous selection of the voters.l

CMS/ESS Examples:  Paul Hoffman discussed this document (without slides). He
is ready to request that the working group chair make a last call for the document
to be published as an Informational RFC.  There is an expectation that an update
to the document will be produced in the future to deal with omissions from the
current document and new examples that employ the AES algorithm.

AES/RSA-OAEP: Jim Schaad presented the current status of the AES/RSA-OAEP draft.
 AES was became FIPS 198 on 16 November 2001. Additionally the AES key wrap
candidate was released in November.  As this is still a draft document, it cannot
be referenced.  An informational track document covering the AES key wrap algorithm
will be produced by the working group.  The authors believe that the AES/RSA-OAEP
draft should be ready for working group last call before the next IETF meeting.

Symmetric Key Distribution:  Sean Turner gave a presentation on the status of
this draft.  He has received a few comments, even though the document has already
passed working group last call.  One set was editorial, and the other was a
request for an additional attribute dealing with security policy.  The latter
request will probably be handled as a separate Internet-Draft to avoid holding
up the symmetric key distribution draft.  So far, an author has not volunteered.

Intended Recipient Attribute:  D. Davis (Curl Corp.) has identified a potential
problem. The concern is that a recipient of signed and encrypted message can
decrypt the message, preserving the original signature, and then resend the
message to a new recipient.  New recipient may act inappropriately based on
the fact that they received a message signed by the original originator, not
the middleman (for further discussion see draft-ietf-smime-sender-auth-00.txt).
 Russ Housley has prepared a potential solution to this problem (see draft-ietf-smime-ira-00.txt).
 Russ presented the problem and his solution to the group, including the benefits
and some potential drawbacks. Jim Schaad then presented a second view of the
problems, attempting to resolve the issue in an Email environment.  In the discussion
that followed Phillip Hallam-Baker raised the point that while this solution
covered the question of the TO and CC header lines, it did nothing to solve
the problem of preventing the leakage of the SUBJECT line in a message.  Following
the discussion two straw polls were taken.  
- Should the sender-auth draft be progressed as an information draft? The vote
was unanimously no.
- Should the ira draft be progressed and if so on what track?  The vote was
unanimously for non-progression of this document as well.
Russ Housley took an action item to bring the question of general protection
of the headers to the mail list.

Policy Requirements for TSAs: Denis Pinkas presented the status of the ETSI
document on this topic.  The final version of the document has not been published
yet, but the current document is available at http://portal.etsi.org/sec/STF178Task1FinalDraft.pdf.

Signature Delegation: Denis Pinkas then presented some thoughts on a mechanism
for a person to delegate their signature authority.  A possible mechanism using
the id-aa-ets-signerAttr was presented.  Comments on whether the problem should
be addressed by the working group and possible solutions will be discussed further
on the mail list.

Date:   Sun, 6 Jan 2002 16:30:57 +1300 (NZDT)
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>
Subject: Patent application filed for S/MIME and PGP
Sender: [email-masked]

Pointed out by John Kane <[email-masked]> on the openpgp list:

  http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20010055396'.PGNR.&OS=DN/20010055396&RS=DN/20010055396

  Mechanism for efficient private bulk messaging 

  Secure bulk messaging mechanism in which, roughly described, a sender first
  encrypts a message once. The message can be decrypted with a message
  decryption key. These can be symmetric or asymmetric keys. For each
  recipient, the sender then encrypts the message decryption key with the
  recipient's public key. The sender then sends the encrypted message and the
  encrypted message decryption keys to a store-and-forward server.
  Subsequently, one or more recipients connect to the server and retrieve the
  encrypted message and the message encryption key that has been encrypted with
  the recipient's public key. Alternatively, the server can forward these items
  to each individual recipient. The recipient then decrypts the encrypted
  message decryption key with the recipient's private key, resulting in an un-
  encrypted message decryption key. The recipient then decrypts the message
  using the un-encrypted message decryption key.

Could someone located in Washington wander in to the USPTO offices and hit the
examiners over the head with a brick before they can rubberstamp this?

Peter.

Date:  Sun, 6 Jan 2002 16:30:57 +1300 (NZDT)
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>
Subject: Patent application filed for S/MIME and PGP
Sender: [email-masked]

Pointed out by John Kane <[email-masked]> on the openpgp list:

  http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20010055396'.PGNR.&OS=DN/20010055396&RS=DN/20010055396

  Mechanism for efficient private bulk messaging 

  Secure bulk messaging mechanism in which, roughly described, a sender first
  encrypts a message once. The message can be decrypted with a message
  decryption key. These can be symmetric or asymmetric keys. For each
  recipient, the sender then encrypts the message decryption key with the
  recipient's public key. The sender then sends the encrypted message and the
  encrypted message decryption keys to a store-and-forward server.
  Subsequently, one or more recipients connect to the server and retrieve the
  encrypted message and the message encryption key that has been encrypted with
  the recipient's public key. Alternatively, the server can forward these items
  to each individual recipient. The recipient then decrypts the encrypted
  message decryption key with the recipient's private key, resulting in an un-
  encrypted message decryption key. The recipient then decrypts the message
  using the un-encrypted message decryption key.

Could someone located in Washington wander in to the USPTO offices and hit the
examiners over the head with a brick before they can rubberstamp this?

Peter.

Date: Sun, 6 Jan 2002 16:30:57 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Patent application filed for S/MIME and PGP
Sender: [email-masked]

Pointed out by John Kane <[email-masked]> on the openpgp list:

  http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20010055396'.PGNR.&OS=DN/20010055396&RS=DN/20010055396

  Mechanism for efficient private bulk messaging 

  Secure bulk messaging mechanism in which, roughly described, a sender first
  encrypts a message once. The message can be decrypted with a message
  decryption key. These can be symmetric or asymmetric keys. For each
  recipient, the sender then encrypts the message decryption key with the
  recipient's public key. The sender then sends the encrypted message and the
  encrypted message decryption keys to a store-and-forward server.
  Subsequently, one or more recipients connect to the server and retrieve the
  encrypted message and the message encryption key that has been encrypted with
  the recipient's public key. Alternatively, the server can forward these items
  to each individual recipient. The recipient then decrypts the encrypted
  message decryption key with the recipient's private key, resulting in an un-
  encrypted message decryption key. The recipient then decrypts the message
  using the un-encrypted message decryption key.

Could someone located in Washington wander in to the USPTO offices and hit the
examiners over the head with a brick before they can rubberstamp this?

Peter.

Date: Thu, 03 Jan 2002 17:06:30 -0500
To: [email-masked], [email-masked]
From: Michael Chernick <[email-masked]>
Subject: Updated Draft of NIST S/MIME V3 Client Profile Now Available
Cc: Michael Chernick <[email-masked]>, Tim Polk <[email-masked]>
Sender: [email-masked]

--=====================_17140984==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

FYI,

I have posted a new version of the draft S/MIME V3 Client Profile on the web.
You can find it at: http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf

(See http://www.imc.org/ietf-smime/mail-archive/msg00861.html for previous
message with background on the NIST S/MIME V3 Client profile.)

There is also a description of our work at: 
http://csrc.nist.gov/pki/smime/welcome.htm

NIST has solicited comments from you and we have incorporated almost
all changes requested into the new document.  Most comments received were
editorial in nature, or asked for clarification.

The new draft has these major changes from the previous (May, 2001) draft:

      An Executive Summary for Procurement Officials, Implementers, 
Vendors, and
      Others interested in S/MIME Technology from a less technical 
perspective;

      A clarification (in Clause 2.4.4) that the path building requirements 
are intended to
      require that all S/MIME clients be able to transverse 
non-hierarchical (e.g., bridge
      PKIs) as well as hierarchical PKIs;

      Relaxation of the requirement (in Clause 2.3.2) to always require 
user notification
      when an incoming S/MIME message is signed by a certificate that 
contains an email
      address that does not match the email address used as "From" address. 
(This
      change was prompted by NIST's observation that many new certificates 
will not
      contain email addresses.)

The major unresolved comment on the May draft is the issue of mandating
signed receipt processing support.  (See Clauses 2.2., 2.3, and 3.1.)  NIST 
received
a comment requesting that this mandate be dropped.

The comment argued that including a requirement for signed receipt support 
would add
cost and complexity to S/MIME products, and that the cost of this 
additional functionality
should be bourne by the agencies that require this service, enabling other 
agencies that do
not require the service to obtain less complex and less costly S/MIME v3 
client systems.
Agencies that do not want/need signed receipts should not be required to 
request it in their
purchases of messaging systems.

NIST has felt that the additional cost and complexity were justified by 
ubiquity of signed
receipt support among U.S. Federal Agencies.  We intend to resolve this 
issue very soon
and then publish the S/MIME V3 Client Profile. We have almost completed the 
process
of soliciting U.S. Federal Agencies on this issue.

I will be pleased to receive any further comments on the new draft until the
end of January 2002.

(Note:  The old draft and updated information on the NIST S/MIME program are
available at: http://csrc.nist.gov/pki/smime/welcome.htm).

The NIST S/MIME V3 Test Facility (see 
http://csrc.nist.gov/pki/smime/smtest.htm) is
not yet operational, but it is expected to become operational (with limited 
test
cases at first) during the first quarter of 2002.

Thanks,
    Mike Chernick

----------------------------------------------------------------------------------
C. Michael Chernick
+1-301-975-3610   [email-masked]
Computer Security Division
National Institute of Standards and Technology (NIST)
----------------------------------------------------------------------------------

--=====================_17140984==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
FYI,<br>
<br>
I have posted a new version of the draft S/MIME V3 Client Profile on the
web.<br>
You can find it at:
<a href="http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.</a><a href="http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">pdf<br>
<br>
</a>(See http://www.imc.org/ietf-smime/mail-archive/msg00861.html for
previous<br>
message with background on the NIST S/MIME V3 Client profile.)<br>
<br>
There is also a description of our work at:
<a href="http://csrc.nist.gov/pki/smime/welcome.htm" eudora="autourl">http://csrc.nist.gov/pki/smime/welcome.</a><a href="http://csrc.nist.gov/pki/smime/welcome.htm" eudora="autourl">htm<br>
<br>
</a>NIST has solicited comments from you and we have incorporated
almost<br>
all changes requested into the new document.&nbsp; Most comments received
were<br>
editorial in nature, or asked for clarification.<br>
<br>
The new draft has these major changes from the previous (May, 2001)
draft: <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; An Executive Summary for Procurement Officials,
Implementers, Vendors, and<br>
&nbsp;&nbsp;&nbsp;&nbsp; Others interested in S/MIME Technology from a
less technical perspective; <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; A clarification (in Clause 2.4.4) that the path
building requirements are intended to<br>
&nbsp;&nbsp;&nbsp;&nbsp; require that all S/MIME clients be able to
transverse non-hierarchical (e.g., bridge<br>
&nbsp;&nbsp;&nbsp;&nbsp; PKIs) as well as hierarchical PKIs; <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; Relaxation of the requirement (in Clause 2.3.2)
to always require user notification<br>
&nbsp;&nbsp;&nbsp;&nbsp; when an incoming S/MIME message is signed by a
certificate that contains an email<br>
&nbsp;&nbsp;&nbsp;&nbsp; address that does not match the email address
used as &quot;From&quot; address. (This<br>
&nbsp;&nbsp;&nbsp;&nbsp; change was prompted by NIST's observation that
many new certificates will not<br>
&nbsp;&nbsp;&nbsp;&nbsp; contain email addresses.) <br>
<br>
The major unresolved comment on the May draft is the issue of mandating
<br>
signed receipt processing support.&nbsp; (See Clauses 2.2., 2.3, and
3.1.)&nbsp; NIST received<br>
a comment requesting that this mandate be dropped. <br>
<br>
The comment argued that including a requirement for signed receipt
support would add<br>
cost and complexity to S/MIME products, and that <font size=2>the cost of
this additional functionality <br>
should be bourne by the agencies that require this service, enabling
other agencies that do<br>
not require the service to obtain less complex and less costly S/MIME v3
client systems. <br>
Agencies that do not want/need signed receipts should not be required to
request it in their <br>
purchases of messaging systems.<br>
<br>
</font>NIST has felt that the additional cost and complexity were
justified by ubiquity of signed<br>
receipt support among U.S. Federal Agencies.&nbsp; We intend to resolve
this issue very soon <br>
and then publish the S/MIME V3 Client Profile. We have almost completed
the process <br>
of soliciting U.S. Federal Agencies on this issue. <br>
<br>
I will be pleased to receive any further comments on the new draft until
the<br>
end of January 2002.<br>
<br>
(Note:&nbsp; The old draft and updated information on the NIST S/MIME
program are<br>
available at: http://csrc.nist.gov/pki/smime/welcome.htm).<br>
<br>
The NIST S/MIME V3 Test Facility (see
http://csrc.nist.gov/pki/smime/smtest.htm) is <br>
not yet operational, but it is expected to become operational (with
limited test<br>
cases at first) during the first quarter of 2002. <br>
<br>
<br>
Thanks,<br>
&nbsp;&nbsp; Mike Chernick<br>
<x-sigsep><p></x-sigsep>
----------------------------------------------------------------------------------<br>
C. Michael Chernick<br>
+1-301-975-3610&nbsp;&nbsp; [email-masked]<br>
Computer Security Division <br>
National Institute of Standards and Technology (NIST)<br>
----------------------------------------------------------------------------------<br>
<br>
</html>

--=====================_17140984==_.ALT--

Date: Thu, 03 Jan 2002 10:38:06 -0500
From: Thoai Nguyen <[email-masked]>
Reply-To: [email-masked]
Organization: The MITRE Corporation
To: [email-masked]
Subject: S/MIME + ESS Issues
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------7018BBD5395755520DFFA94C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I look for papers that address the following S/MIME +ESS Messaging
issues:

1. Signed returned receipt
2. Security labeling
3. Message type/compartment/category attribute
4. Mail List (distribute outgoing mails)
5. Profiling  (distribute incoming mails)

Your information will be appreciated. Thanks,

>>Thoai

--------------7018BBD5395755520DFFA94C
Content-Type: text/x-vcard; charset=us-ascii;
 name="thoai.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Thoai Nguyen
Content-Disposition: attachment;
 filename="thoai.vcf"

begin:vcard 
n:Nguyen;Thoai
tel;fax:703-883-3383
tel;home:703-916-7831
tel;work:703-883-7228
x-mozilla-html:TRUE
org:The MITRE Corporation;WO35
version:2.1
email;internet:[email-masked]
title:Senior Network/Distributed Engineer
adr;quoted-printable:;;M/S 658=0D=0A1820 Dolley Madison Blvd.;McLean;VA;22102-3481;USA
fn:Thoai Nguyen
end:vcard

--------------7018BBD5395755520DFFA94C--