RE: (Practical) S/MIME certificate chain handling

["Blake Ramsdell" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Monday, June 30, 2003 3:35 AM
> To: Blake Ramsdell; [e-mail]; [e-mail]
> Subject: Re: (Practical) S/MIME certificate chain handling
> 
> > I believe that most clients transmit the certificate chain (not
> > including the root) today.
> 
> To the best of my knowledge, Outlook does not, and it has 
> quite a large
> market share ... (Although, I'd be happy to know how to make 
> it do so if
> there is a way ;) ).

Outlook 2002 sends all the certificates in the chain (I just verified
this).  When Jim Schaad wrote the code way back in something like
Outlook 97, I'm fairly certain that it sent all the certificates also.
This could very well be a case of misconfiguration of some sort, and I'd
be happy to work through it with you offline.  The early S/MIME
implementations all understood the utility of this, and included the
certificates for exactly the reasons that you cite.

> I guess I would really like to be able to send a signed 
> S/MIME email to
> someone with whom I only share a root CA, and that all 
> verifications can
> be made ... Because we do not have interconnected directories yet, the
> sender definitely has to send the full chain (up but not including the
> root), but the client should also be able to check CRL and/or 
> OCSP. Some
> clients support these, but they often have to be configured manually.

I agree, and that's why they send all the certificates along with
messages to this date.  By "they", I mean S/MIME-enabled versions of
Netscape, Outlook Express, Outlook, and the S/MIME plugin for Eudora
that I wrote.  Granted, there could have been some change in those
clients since I've used them (I haven't used Netscape for awhile, but
Outlook Express and Outlook are in regular use here in the 'Labs, and I
know some people are still using the Eudora plugin).  Unfortunately
we're speaking in generalities here, so you and I need to have a
discussion and find out exactly what is going on with current clients to
make sure that we understand if there's a problem, and who needs to
address it.

> There are five PKIX extensions which receiving agents MUST support,
> indicated in section 4.4 of rfc2632bis. It would be quite nice that
> receiving agents also support "CRL Distribution Points", and even
> maybe "Authority Information Access".

This starts getting into a thorny area.  Basically I've been waiting for
seven years for the certificate distribution and revocation checking
problem to get sorted out and it hasn't happened.  It is not clear what
the "correct" revocation direction is, so we defer to "whatever PKIX
says" and "whatever your environment uses".  That's a crappy answer, but
we've been careful not to infringe on PKIX's charter and their solutions
to this problem.  I'll just stop talking right now, lest I say something
mean ;).

> More generally, we have
> (1) the trusted common info (the root CA)
> (2) the verification information (cert chains, crl, OCSP)

Agreed.

> Many email clients do implement services to retrieve or access
> directories, CRL and OCSP, but they need to know _where_ to 
> access them.

Agreed.

> Ideally, I think sending agent should include either (2), or 
> indications
> on where to retrieve (2). Maybe S/MIME should encourage the usage of
> the aforementionned extensions ?

I think we should encourage "whatever PKIX says to use", which is what
we do.  It's up to the working group if we want to undertake this
effort, and what form it will take.  It is much larger, I think, than
saying "hey, just use this extension of the certificates".

> If I have to phone my email recipient to explain him: go on such web
> page, click on "download intermediate CA", follow the procedure,
> then click on "enable CRL", enter some.address.com/crl/class27-3.crl
> I could also spell out the hash of my cert, and get rid of CAs ;)

That's exactly what we did in the S/MIME implementations that I've
worked on -- there is a "direct trust" option that you verify the MD5
hash of the certificate.  In practice, it worked quite well because it
was mostly server-to-server configuration, and we never dealt with
revocation.  So, kidding or not, it actually works in small, closed
environments where they can tell you in person if they lost their
private key ;).

> Just kidding of course, but the information currently commonly
> transmitted in S/MIME emails is often not sufficient to 
> enable automatic
> signature verification without preliminary manual configuration, for
> each specific sender or group of senders.

I just don't agree with this statement, and I consider it to be too
general.  Like I said, my focus is on the MS clients and our own code,
and they perform well with the exception of a) working with an unknown
root and b) no consistent revocation option.  The Verisign certs come
with a CRLDP extension that we honor, but I can't speak about other
clients.  So Verisign certificates (which have a root installed in all
the clients and use CRLDP and have CRLs available) work right now.  For
other roots and the associated revocation algorithm du jour, that's a
separate problem, and I worry about how much we can address it here.

Blake




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMe6FK083158 for <[e-mail]>; Mon, 30 Jun 2003 15:40:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UMe6Os083157 for ietf-smime-bks; Mon, 30 Jun 2003 15:40:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMe5FK083152 for <[e-mail]>; Mon, 30 Jun 2003 15:40:05 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Mon, 30 Jun 2003 15:40:01 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Mon, 30 Jun 2003 15:40:01 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAHQr9HqmMOESm/[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.2800.1165
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Monday, June 30, 2003 3:35 AM
> To: Blake Ramsdell; [e-mail]; [e-mail]
> Subject: Re: (Practical) S/MIME certificate chain handling
> 
> > I believe that most clients transmit the certificate chain (not
> > including the root) today.
> 
> To the best of my knowledge, Outlook does not, and it has 
> quite a large
> market share ... (Although, I'd be happy to know how to make 
> it do so if
> there is a way ;) ).

Outlook 2002 sends all the certificates in the chain (I just verified
this).  When Jim Schaad wrote the code way back in something like
Outlook 97, I'm fairly certain that it sent all the certificates also.
This could very well be a case of misconfiguration of some sort, and I'd
be happy to work through it with you offline.  The early S/MIME
implementations all understood the utility of this, and included the
certificates for exactly the reasons that you cite.

> I guess I would really like to be able to send a signed 
> S/MIME email to
> someone with whom I only share a root CA, and that all 
> verifications can
> be made ... Because we do not have interconnected directories yet, the
> sender definitely has to send the full chain (up but not including the
> root), but the client should also be able to check CRL and/or 
> OCSP. Some
> clients support these, but they often have to be configured manually.

I agree, and that's why they send all the certificates along with
messages to this date.  By "they", I mean S/MIME-enabled versions of
Netscape, Outlook Express, Outlook, and the S/MIME plugin for Eudora
that I wrote.  Granted, there could have been some change in those
clients since I've used them (I haven't used Netscape for awhile, but
Outlook Express and Outlook are in regular use here in the 'Labs, and I
know some people are still using the Eudora plugin).  Unfortunately
we're speaking in generalities here, so you and I need to have a
discussion and find out exactly what is going on with current clients to
make sure that we understand if there's a problem, and who needs to
address it.

> There are five PKIX extensions which receiving agents MUST support,
> indicated in section 4.4 of rfc2632bis. It would be quite nice that
> receiving agents also support "CRL Distribution Points", and even
> maybe "Authority Information Access".

This starts getting into a thorny area.  Basically I've been waiting for
seven years for the certificate distribution and revocation checking
problem to get sorted out and it hasn't happened.  It is not clear what
the "correct" revocation direction is, so we defer to "whatever PKIX
says" and "whatever your environment uses".  That's a crappy answer, but
we've been careful not to infringe on PKIX's charter and their solutions
to this problem.  I'll just stop talking right now, lest I say something
mean ;).

> More generally, we have
> (1) the trusted common info (the root CA)
> (2) the verification information (cert chains, crl, OCSP)

Agreed.

> Many email clients do implement services to retrieve or access
> directories, CRL and OCSP, but they need to know _where_ to 
> access them.

Agreed.

> Ideally, I think sending agent should include either (2), or 
> indications
> on where to retrieve (2). Maybe S/MIME should encourage the usage of
> the aforementionned extensions ?

I think we should encourage "whatever PKIX says to use", which is what
we do.  It's up to the working group if we want to undertake this
effort, and what form it will take.  It is much larger, I think, than
saying "hey, just use this extension of the certificates".

> If I have to phone my email recipient to explain him: go on such web
> page, click on "download intermediate CA", follow the procedure,
> then click on "enable CRL", enter some.address.com/crl/class27-3.crl
> I could also spell out the hash of my cert, and get rid of CAs ;)

That's exactly what we did in the S/MIME implementations that I've
worked on -- there is a "direct trust" option that you verify the MD5
hash of the certificate.  In practice, it worked quite well because it
was mostly server-to-server configuration, and we never dealt with
revocation.  So, kidding or not, it actually works in small, closed
environments where they can tell you in person if they lost their
private key ;).

> Just kidding of course, but the information currently commonly
> transmitted in S/MIME emails is often not sufficient to 
> enable automatic
> signature verification without preliminary manual configuration, for
> each specific sender or group of senders.

I just don't agree with this statement, and I consider it to be too
general.  Like I said, my focus is on the MS clients and our own code,
and they perform well with the exception of a) working with an unknown
root and b) no consistent revocation option.  The Verisign certs come
with a CRLDP extension that we honor, but I can't speak about other
clients.  So Verisign certificates (which have a root installed in all
the clients and use CRLDP and have CRLs available) work right now.  For
other roots and the associated revocation algorithm du jour, that's a
separate problem, and I worry about how much we can address it here.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UBssFK060873 for <[e-mail]>; Mon, 30 Jun 2003 04:54:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UBssoF060872 for ietf-smime-bks; Mon, 30 Jun 2003 04:54:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UBsAFK060845 for <[e-mail]>; Mon, 30 Jun 2003 04:54:14 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12726; Mon, 30 Jun 2003 07:54:05 -0400 (EDT)
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-camellia-04.txt
Date: Mon, 30 Jun 2003 07:54:05 -0400
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		: Use of the Camellia Encryption Algorithm in CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-04.txt
	Pages		: 11
	Date		: 2003-6-27
	
This document specifies the conventions for using the Camellia
encryption algorithm for encryption with the Cryptographic
Message Syntax (CMS).

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UAZ7FK058399 for <[e-mail]>; Mon, 30 Jun 2003 03:35:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UAZ7bl058398 for ietf-smime-bks; Mon, 30 Jun 2003 03:35:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UAZ6FK058390 for <[e-mail]>; Mon, 30 Jun 2003 03:35:06 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 450F340E81; Mon, 30 Jun 2003 12:35:05 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id E6F0853F8; Mon, 30 Jun 2003 12:35:04 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 01922-04; Mon, 30 Jun 2003 12:35:04 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id AA2FA53F7; Mon, 30 Jun 2003 12:35:04 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 30 Jun 2003 12:35:04 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 30 Jun 2003 12:35:04 +0200
To: Blake Ramsdell <[e-mail]>, [e-mail], [e-mail]
Subject: Re: (Practical) S/MIME certificate chain handling
Message-ID: <[e-mail]>
References: <[e-mail]> <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at example.com
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 Mon, Jun 30, 2003 at 02:15:03AM -0700, Blake Ramsdell wrote:
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Monday, June 30, 2003 1:10 AM
> > To: [e-mail]; [e-mail]
> > Subject: Re: (Practical) S/MIME certificate chain handling
> > 
> > So to summarize, I was wondering whether it would be a good idea to
> > mandate that clients should sent as much info as possible so 
> > as to help
> > signature verification, or at least provide the user with the 
> > option to
> > do so. Naturally, none of these info should include root 
> > trust anchors.


> I believe that most clients transmit the certificate chain (not
> including the root) today.

To the best of my knowledge, Outlook does not, and it has quite a large
market share ... (Although, I'd be happy to know how to make it do so if
there is a way ;) ).

> It's not clear what action we can take that would make life nicer for
> everyone -- we already have language in 2632bis:
> 
> <verbatim>
> Sending agents SHOULD include any certificates for the user's public
> key(s) and associated issuer certificates. This increases the
> likelihood that the intended recipient can establish trust in the
> originator's public key(s). This is especially important when sending
> a message to recipients that may not have access to the sender's
> public key through any other means or when sending a signed message to
> a new recipient. The inclusion of certificates in outgoing messages
> can be omitted if S/MIME objects are sent within a group of
> correspondents that has established access to each other's
> certificates by some other means such as a shared directory or manual
> certificate distribution. Receiving S/MIME agents SHOULD be able to
> handle messages without certificates using a database or directory
> lookup scheme.
> </verbatim>
> 
> If there is something I'm missing, please let me know.  This is a SHOULD
> recommendation.

I'm afraid this cannot be made much clearer, you are right ...

I guess I would really like to be able to send a signed S/MIME email to
someone with whom I only share a root CA, and that all verifications can
be made ... Because we do not have interconnected directories yet, the
sender definitely has to send the full chain (up but not including the
root), but the client should also be able to check CRL and/or OCSP. Some
clients support these, but they often have to be configured manually.

There are five PKIX extensions which receiving agents MUST support,
indicated in section 4.4 of rfc2632bis. It would be quite nice that
receiving agents also support "CRL Distribution Points", and even
maybe "Authority Information Access".

More generally, we have
(1) the trusted common info (the root CA)
(2) the verification information (cert chains, crl, OCSP)

Many email clients do implement services to retrieve or access
directories, CRL and OCSP, but they need to know _where_ to access them.

Ideally, I think sending agent should include either (2), or indications
on where to retrieve (2). Maybe S/MIME should encourage the usage of
the aforementionned extensions ?

If I have to phone my email recipient to explain him: go on such web
page, click on "download intermediate CA", follow the procedure,
then click on "enable CRL", enter some.address.com/crl/class27-3.crl
I could also spell out the hash of my cert, and get rid of CAs ;)

Just kidding of course, but the information currently commonly
transmitted in S/MIME emails is often not sufficient to enable automatic
signature verification without preliminary manual configuration, for
each specific sender or group of senders.

--
Julien Stern


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U9F9FK054253 for <[e-mail]>; Mon, 30 Jun 2003 02:15:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5U9F9Oa054252 for ietf-smime-bks; Mon, 30 Jun 2003 02:15:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U9F8FK054245 for <[e-mail]>; Mon, 30 Jun 2003 02:15:08 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Mon, 30 Jun 2003 02:15:03 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Mon, 30 Jun 2003 02:15:03 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Monday, June 30, 2003 1:10 AM
> To: [e-mail]; [e-mail]
> Subject: Re: (Practical) S/MIME certificate chain handling
> 
> So to summarize, I was wondering whether it would be a good idea to
> mandate that clients should sent as much info as possible so 
> as to help
> signature verification, or at least provide the user with the 
> option to
> do so. Naturally, none of these info should include root 
> trust anchors.

I believe that most clients transmit the certificate chain (not
including the root) today.

It's not clear what action we can take that would make life nicer for
everyone -- we already have language in 2632bis:

<verbatim>
Sending agents SHOULD include any certificates for the user's public
key(s) and associated issuer certificates. This increases the
likelihood that the intended recipient can establish trust in the
originator's public key(s). This is especially important when sending
a message to recipients that may not have access to the sender's
public key through any other means or when sending a signed message to
a new recipient. The inclusion of certificates in outgoing messages
can be omitted if S/MIME objects are sent within a group of
correspondents that has established access to each other's
certificates by some other means such as a shared directory or manual
certificate distribution. Receiving S/MIME agents SHOULD be able to
handle messages without certificates using a database or directory
lookup scheme.
</verbatim>

If there is something I'm missing, please let me know.  This is a SHOULD
recommendation.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U89rFK051284 for <[e-mail]>; Mon, 30 Jun 2003 01:09:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5U89rNo051283 for ietf-smime-bks; Mon, 30 Jun 2003 01:09:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U89pFK051277 for <[e-mail]>; Mon, 30 Jun 2003 01:09:52 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 1F2E940EFA; Mon, 30 Jun 2003 10:09:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 58ACB4133; Mon, 30 Jun 2003 10:09:44 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 01372-02; Mon, 30 Jun 2003 10:09:44 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 2294040B3; Mon, 30 Jun 2003 10:09:44 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 30 Jun 2003 10:09:44 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 30 Jun 2003 10:09:44 +0200
To: [e-mail], [e-mail]
Subject: Re: (Practical) S/MIME certificate chain handling
Message-ID: <[e-mail]>
References: <[e-mail]> <009801c33ce3$f83cc200$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <009801c33ce3$f83cc200$[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at example.com
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 certainly not suggesting to sent the root certificate.

My point was the following: quite often, when one receives a
signed email, there is only the end-user cert.

So, it is the responsability or the receiver to retrieve the possibly
many subordinate CA certs, to figure out where the CRL is, if there
is an OCSP responder, to find out where is it, etc.

So, sure, when there will be a global worldwide interconnected directory
service which would include information on all these items, the sender
won't even have to sent his own certificate, but right now, the behavior
of some email clients, with which you cannot even send the subordinate
CA certs, seems problematic to me.

So to summarize, I was wondering whether it would be a good idea to
mandate that clients should sent as much info as possible so as to help
signature verification, or at least provide the user with the option to
do so. Naturally, none of these info should include root trust anchors.

--
Julien

On Fri, Jun 27, 2003 at 12:40:30PM -0700, Jim Schaad wrote:
> Julien,
> 
> I am not sure that I see any added benefit in sending the root
> certificate as part of a signed message.  If you don't already have the
> certificate as a trusted certificate then you cannot make any additional
> statements about the fact that you do or do not trust the signature on
> the message you just received.
> 
> jim
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Thursday, June 26, 2003 7:27 AM
> > To: [e-mail]
> > Subject: (Practical) S/MIME certificate chain handling
> > 
> > 
> > 
> > Hi all,
> > 
> > I have a question regarding certificate chain verification 
> > when receiving a signed email.
> > 
> > rfc2632bis-03.txt says that
> > 
> >   "A receiving agent needs to provide some certificate retrieval
> >   mechanism in order to gain access to certificates for recipients of
> >   digital envelopes."
> > 
> > And then explains that X.500 (or LDAP) directories could be 
> > used, or maybe the DNS system, or that the certificates could 
> > be transmitted in the mail.
> > 
> > In the (very) long run, directories of some kind (where both 
> > certificates and crl could be checked), or a remote chain 
> > verification server as investigated by PKIX, seem to be nice 
> > solutions.
> > 
> > However, nowadays, such systems are highly manual at best, 
> > and totally inexistent in most cases, hence, it would seem 
> > reasonnable to provide the full chain of certificates needed 
> > to verify the sender's one(s), as suggested by CMS (RFC2632) :
> > 
> >   "certificates is a collection of certificates. It is 
> > intended that the
> >   set of certificates be sufficient to contain chains from a 
> > recognized
> >   "root" or "top-level certification authority" to all of the 
> > signers in
> >   the signerInfos field. There may be more certificates than 
> > necessary,
> >   and there may be certificates sufficient to contain chains 
> > from two or
> >   more independent top- level certification authorities. 
> > There may also
> >   be fewer certificates than necessary, if it is expected 
> > that recipients
> >   have an alternate means of obtaining necessary certificates 
> > (e.g., from
> >   a previous set of certificates)."
> > 
> > 
> > This fairly natural behavior is implemented in Outlook 
> > Express, Netscape, Mozilla, Notes, OpenSSL, etc. Oddly 
> > enough, Outlook seem to only send the sender certificate, and 
> > does not seem to provide a way to send the full chain, making 
> > it quite unusable in practice for secure email.
> > 
> > While I might have overlooked an option which actually allows 
> > the sending of a full chain, do you think it would be 
> > reasonnable, and in the scope and the spirit of the S/MIME 
> > Working Group, to mandate that client MUST(?)/SHOULD(?) have 
> > an option that sends all information available to validate 
> > the sender cert (cert chain + possibly crl and/or OCSP).
> > 
> > This option, especially if mandatory, would be of great use 
> > to facilitate the widespread adoption of S/MIME, and could be 
> > deactivated for efficiency reasons when directories (or a 
> > similar alternate system) are widely deployed.
> > 
> > Thanks for your time.
> > Sincerely,
> > 
> > --
> > Julien Stern
> > 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S5HXrb075862 for <[e-mail]>; Fri, 27 Jun 2003 22:17:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5S5HXTF075861 for ietf-smime-bks; Fri, 27 Jun 2003 22:17:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S5HWrb075856 for <[e-mail]>; Fri, 27 Jun 2003 22:17:32 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 8A6C16A8CA; Fri, 27 Jun 2003 21:55:53 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 27 Jun 2003 22:17:37 -0700
Message-ID: <00a801c33d34$976fdbf0$[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.2800.1165
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAA8ACLXH4Ia0COPX30/[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>

Blake,


> I see a few ways to proceed, in my personal preference order:
> 
> 1. Commit to the current direction of using the MSG draft to 
> define how to use MIME with everything in CMS, as well as 
> providing a constrained subset of CMS for the purpose of 
> interpersonal messaging.
> 
> 2. Don't put anything in MSG at all that doesn't have to do 
> with interpersonal messaging, but leave what's there (the 
> definition of the application/pkcs7-mime and the currently 
> used smime-types).  Any additional smime-type values are 
> defined outside of the MSG draft.
> 
> 3. Separate everything that has to do with the MIME wrapping 
> of CMS objects into its own draft (CMS/MIME), and don't 
> discuss anything about interpersonal messaging at all.  The 
> MSG draft simply contains references to the CMS/MIME draft, 
> and is a profile of it.  This is somewhat like the separation 
> of CMS and CMSALG, I think.
> 
> I will admit that my preference order is influenced by my 
> role as the editor, and the desire to see MSG progress sooner 
> rather than later.

I have one argument for varient 3 that I just thought of that might be
overwelming at a later date, but certiantly not currently.  If SIP is
dependent on the CMS/SMIME/Messaging draft, and we update that draft for
a messaging only item, then SIP gets reset on its progression path as
well.  I don't think this is an immeadiate issue, but something to
consider in the future.

If we go with the version 1 draft, then we should perhaps look at
reorginaizing the draft along the lines of looking like a profile of a
previously defined item rather than having items intermixed.  I have not
looked at the documents to see how intermixed messaging is with the
document and will do so later this weekend.

> 
> Blake
> 

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S46arb074111 for <[e-mail]>; Fri, 27 Jun 2003 21:06:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5S46a9a074110 for ietf-smime-bks; Fri, 27 Jun 2003 21:06:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S46Zrb074104 for <[e-mail]>; Fri, 27 Jun 2003 21:06:35 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 27 Jun 2003 21:06:32 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 27 Jun 2003 21:06:32 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAA8ACLXH4Ia0COPX30/[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.2800.1165
Importance: Normal
In-Reply-To: <00a301c33d1d$636c3e50$[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>

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]] 
> Sent: Friday, June 27, 2003 7:32 PM
> To: 'Blake Ramsdell'
> Cc: [e-mail]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
> Is the message document correctly titled "How to do secure MIME with
> CMS" or "How to do secure messaging with MIME and CMS"?

I agree that this is something important to understand.  As you point
out, one view of the world is:

CMS -> S/MIME -> Non-email

And another is:

CMS -> S/MIME -> Email

And combined you might have:

CMS -> S/MIME +-> Email
              |
              +-> Non-email

Where each node (other than CMS) represents a profile.

> If the answer is the first, then this should be done.  If the 
> answer is
> the latter (and this is the position that most people think from) then
> this should not be done and a separate draft should be 
> written on how to
> do the additional CMS security types.

I think that that we intended it to be "securing messaging" but its role
is starting to expand to "securing MIME in general", with recent
interest from SIP and XMPP for the latter.  Despite the title which
implies "securing MIME in general", it has things in it that are very
specific to the problem domain of interpersonal messaging, and have
nothing to do with the general problem of securing MIME in CMS
(preferences negotiation, transfer type recommendations, etc.).

We're heading in the direction of fixing this by combining the Email and
Non-email profiles of S/MIME within the S/MIME profile.  It is both a
list of ways that you use CMS with MIME in general, and a profile that
explains how to do interpersonal messaging with it.

> I don't really want to bifercate the current Message and Certificate
> drafts to have different documents for both the first and the second
> (although the latter documents would be a "simple" profile of 
> the former
> documents). But I think we need as a group to make a decision on what
> document we are writing.

I am fairly certain that a profile that defines MIME packaging for all
of the CMS types would be useful, and one group is ready to use it right
now (SIP).  I don't like the idea of scattering the registry of
smime-type between multiple documents, but perhaps that is inevitable.

I see a few ways to proceed, in my personal preference order:

1. Commit to the current direction of using the MSG draft to define how
to use MIME with everything in CMS, as well as providing a constrained
subset of CMS for the purpose of interpersonal messaging.

2. Don't put anything in MSG at all that doesn't have to do with
interpersonal messaging, but leave what's there (the definition of the
application/pkcs7-mime and the currently used smime-types).  Any
additional smime-type values are defined outside of the MSG draft.

3. Separate everything that has to do with the MIME wrapping of CMS
objects into its own draft (CMS/MIME), and don't discuss anything about
interpersonal messaging at all.  The MSG draft simply contains
references to the CMS/MIME draft, and is a profile of it.  This is
somewhat like the separation of CMS and CMSALG, I think.

I will admit that my preference order is influenced by my role as the
editor, and the desire to see MSG progress sooner rather than later.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S2VRrb072421 for <[e-mail]>; Fri, 27 Jun 2003 19:31:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5S2VR1d072420 for ietf-smime-bks; Fri, 27 Jun 2003 19:31:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S2VQrb072415 for <[e-mail]>; Fri, 27 Jun 2003 19:31:26 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 980766ACB4; Fri, 27 Jun 2003 19:31:28 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 27 Jun 2003 19:31:30 -0700
Message-ID: <00a301c33d1d$636c3e50$[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.2800.1165
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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>

Blake,

I have both a very basic and a very complicated answer to this
questions.

Is the message document correctly titled "How to do secure MIME with
CMS" or "How to do secure messaging with MIME and CMS"?

If the answer is the first, then this should be done.  If the answer is
the latter (and this is the position that most people think from) then
this should not be done and a separate draft should be written on how to
do the additional CMS security types.

I don't really want to bifercate the current Message and Certificate
drafts to have different documents for both the first and the second
(although the latter documents would be a "simple" profile of the former
documents). But I think we need as a group to make a decision on what
document we are writing.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Blake Ramsdell
> Sent: Thursday, June 19, 2003 3:51 PM
> To: 'Rohan Mahy'
> Cc: [e-mail]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Rohan Mahy
> > Sent: Friday, June 06, 2003 7:59 PM
> > To: Blake Ramsdell
> > Cc: [e-mail]; [e-mail]
> > Subject: proposed addition to application/pkcs7-mime smime parameter
> > 
> > I have included some proposed text to add the other CMS types to the
> > smime-type mime parameter.  Alternatively a new cms-type mime 
> > parameter 
> > could be defined, but this seems a but pedantic to me.
> 
> We are in a strange situation here, and I'd like to get 
> feedback on this.  One side of me says that the 
> "application/pkcs7-mime" means "MIME packaged in PKCS #7 
> (which then became CMS) for the purpose of moving around 
> secured MIME entities".  I don't know if it's a better idea 
> to a) overload the application/pkcs7-mime type to mean "CMS, 
> possibly not wrapped in MIME", or b) introduce 
> application/cms in a separate draft, along with a cms-type 
> parameter that explains the inner type.
> 
> I know that there was much discussion about application/xml 
> in a similar context, and I don't know if there's anything we 
> can learn from that in order to resolve this.  It seems that 
> the application/xml semantic would be very similar to the 
> application/cms semantic, but I may not understand it correctly.
> 
> I'm going to release 2633bis-05 shortly, and if there's no 
> discussion on this topic I'm not going to include anything in 
> that draft.  If it's important, we should work through it.
> 
> Blake
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S1sDrb071758 for <[e-mail]>; Fri, 27 Jun 2003 18:54:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5S1sDO6071757 for ietf-smime-bks; Fri, 27 Jun 2003 18:54:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S1sBrb071752 for <[e-mail]>; Fri, 27 Jun 2003 18:54:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 956FB6F476; Fri, 27 Jun 2003 18:54:13 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Fri, 27 Jun 2003 18:54:17 -0700
Message-ID: <009d01c33d18$2f7d34f0$[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.2800.1165
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>

Chris,

I hope there is a great deal more to this than what you are stating for
a Best Practice recommendation.

1.  Acceptance of root certificates by end-users is a real problem.
They tend to say yes without any good reason to do so.  This means that
it is easy to stick "bad" root certificates on a persons machine (and
thus do future spoofing) by simply sending a full certificate chain with
a message.

2.  Sending an OCSP or CRL with a message generally does not do a great
deal of good unless you are having long lived items (in which case they
may be incorrect).  In many cases either 1) the CRL/OCSP response is out
of date or 2) the OCSP response is not known to me.

If you are really working in a single structure, then this information
should be automatically distributed to people's machines and not send
from the sender.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Friday, June 27, 2003 3:43 AM
> To: Julien Stern
> Cc: [e-mail]
> Subject: Re: (Practical) S/MIME certificate chain handling
> 
> 
> 
> 
> 
> 
> 
> 
> > While I might have overlooked an option which actually allows the 
> > sending of a full chain, do you think it would be 
> reasonable, and in 
> > the scope and the spirit of the S/MIME Working Group, to 
> mandate that 
> > client MUST(?)/SHOULD(?) have an option that sends all information 
> > available to validate the sender cert (cert chain + possibly crl 
> > and/or OCSP).
> 
> This behaviour came out as a Best Practice recommendation 
> from the analysis of the results for the recent EEMA PKI 
> Challenge project.
> 
> Chris
> Royal Mail is a trading name of Royal Mail Group plc. 
> Registered in England and Wales. Registered number 4138203. 
> Registered office at 148 Old Street, LONDON EC1V 9HQ
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RLBqrb064169 for <[e-mail]>; Fri, 27 Jun 2003 14:11:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5RLBqV5064167 for ietf-smime-bks; Fri, 27 Jun 2003 14:11:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RLBprb064161 for <[e-mail]>; Fri, 27 Jun 2003 14:11:51 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 27 Jun 2003 14:11:48 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: Discussing RTCS
Date: Fri, 27 Jun 2003 14:11:48 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
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>

Peter Gutmann has made an individual draft submission for his CMS-based
RTCS protocol.  A URL to this draft is:

http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt

He would like to get some review of the CMS parts of this, and it seems
reasonable to discuss it here on the IETF-SMIME list if there is
interest.

Since this draft is CMS based and potentially adds value to CMS or
S/MIME in general, should we consider bringing it into this working
group?

Comments?

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJeRrb060633 for <[e-mail]>; Fri, 27 Jun 2003 12:40:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5RJeRGo060632 for ietf-smime-bks; Fri, 27 Jun 2003 12:40:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJeQrb060627 for <[e-mail]>; Fri, 27 Jun 2003 12:40:26 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 2A94E6F816; Fri, 27 Jun 2003 12:40:27 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Fri, 27 Jun 2003 12:40:30 -0700
Message-ID: <009801c33ce3$f83cc200$[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.2800.1165
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>

Julien,

I am not sure that I see any added benefit in sending the root
certificate as part of a signed message.  If you don't already have the
certificate as a trusted certificate then you cannot make any additional
statements about the fact that you do or do not trust the signature on
the message you just received.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Thursday, June 26, 2003 7:27 AM
> To: [e-mail]
> Subject: (Practical) S/MIME certificate chain handling
> 
> 
> 
> Hi all,
> 
> I have a question regarding certificate chain verification 
> when receiving a signed email.
> 
> rfc2632bis-03.txt says that
> 
>   "A receiving agent needs to provide some certificate retrieval
>   mechanism in order to gain access to certificates for recipients of
>   digital envelopes."
> 
> And then explains that X.500 (or LDAP) directories could be 
> used, or maybe the DNS system, or that the certificates could 
> be transmitted in the mail.
> 
> In the (very) long run, directories of some kind (where both 
> certificates and crl could be checked), or a remote chain 
> verification server as investigated by PKIX, seem to be nice 
> solutions.
> 
> However, nowadays, such systems are highly manual at best, 
> and totally inexistent in most cases, hence, it would seem 
> reasonnable to provide the full chain of certificates needed 
> to verify the sender's one(s), as suggested by CMS (RFC2632) :
> 
>   "certificates is a collection of certificates. It is 
> intended that the
>   set of certificates be sufficient to contain chains from a 
> recognized
>   "root" or "top-level certification authority" to all of the 
> signers in
>   the signerInfos field. There may be more certificates than 
> necessary,
>   and there may be certificates sufficient to contain chains 
> from two or
>   more independent top- level certification authorities. 
> There may also
>   be fewer certificates than necessary, if it is expected 
> that recipients
>   have an alternate means of obtaining necessary certificates 
> (e.g., from
>   a previous set of certificates)."
> 
> 
> This fairly natural behavior is implemented in Outlook 
> Express, Netscape, Mozilla, Notes, OpenSSL, etc. Oddly 
> enough, Outlook seem to only send the sender certificate, and 
> does not seem to provide a way to send the full chain, making 
> it quite unusable in practice for secure email.
> 
> While I might have overlooked an option which actually allows 
> the sending of a full chain, do you think it would be 
> reasonnable, and in the scope and the spirit of the S/MIME 
> Working Group, to mandate that client MUST(?)/SHOULD(?) have 
> an option that sends all information available to validate 
> the sender cert (cert chain + possibly crl and/or OCSP).
> 
> This option, especially if mandatory, would be of great use 
> to facilitate the widespread adoption of S/MIME, and could be 
> deactivated for efficiency reasons when directories (or a 
> similar alternate system) are widely deployed.
> 
> Thanks for your time.
> Sincerely,
> 
> --
> Julien Stern
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJcDrb060580 for <[e-mail]>; Fri, 27 Jun 2003 12:38:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5RJcDT4060579 for ietf-smime-bks; Fri, 27 Jun 2003 12:38:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJcCrb060571 for <[e-mail]>; Fri, 27 Jun 2003 12:38:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 058756DAC8; Fri, 27 Jun 2003 12:38:13 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'g.lunt'" <[e-mail]>, "'Sean P. Turner'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Signed Receipts and Mail Lists
Date: Fri, 27 Jun 2003 12:38:16 -0700
Message-ID: <009701c33ce3$a86b4170$[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.2800.1165
Importance: Normal
In-Reply-To: <001101c33aec$fee550c0$[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>

Sean,

I have had many discussions with people on this issue.  It is very
likely that an MLA would return a receipt to the originator of the
message either on initial receipt (I got it and distributed it) or after
a specific percentage of people on the list have returned receipts.
This is the only way to handle receipts in the case of a mailing list
whose memebership is hidden from senders.  

This being said the problem here is that you are using a single
certificate for two distinct individuals (i.e. the two different mailing
lists) and asking somebody (the sender of the message) to try and guess
which indiviual was being refered to.  In this case each MLA should have
it's own certificate (and hopefully different key pairs) in order to
allow for distinctness of identity to be known.

Graeme,

If we adopted the solution you gave, what limits me from making
arbitrary statements about who I am in this field that then need to be
independently verified by the receipt processing code?  (I.e. what if I
put the fact that I am [e-mail] in this field and sign with my
[e-mail] certificate).

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Graeme Lunt
> Sent: Wednesday, June 25, 2003 12:40 AM
> To: 'Sean P. Turner'
> Cc: 'ietf-smime'
> Subject: RE: Signed Receipts and Mail Lists
> 
> 
> 
> Sean,
>  
> > I'm not sure that the MLA returns a receipt on behalf of the ML 
> > members.
> 
> OK - if an MLA should not return signed receipts then there 
> is not a problem with my scenario. 
> 
> > I looked through ESS again and I couldn't find anything 
> that said if a  
> > message enters an MLA with a signed receipt request that it
> 
> > shouldn't or should return a receipt.    
> 
> Is an MLA considered a "receiving agent"/"receiving 
> software"/"processing software" in section 2.3 of ESS? I had 
> assumed that it was but agree it is unclear.
> 
> > Typically (I think), originators want to know that the 
> final recipient
> got 
> > the message not whether the MLA got it.
> 
> I think there are arguments for both. If an originator sends a message
> to:
> 
> [e-mail]
> 
> the originator probably only wants to know that it got to the 
> complaints department at bigbank. The originator doesn't want 
> to know (and bigbank doesn't want to let the originator know) 
> which individuals within bigbank read the message.
> 
> > Then again maybe I didn't understand your scenario.
> 
> I don't think the originator needs to understand if the 
> addresses they are requesting signed receipts from are 
> address lists or not. If an originator sends a message to two 
> recipients - one a mail list, one an individual - and 
> requests first tier signed receipts, they will never receive 
> a signed receipt from the mail list recipient. The user may 
> find this unexpected. Correlation software *may* be able to 
> detect a mail list recipient and handle it appropriately.
> 
> 
> Graeme
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R9hErb022862 for <[e-mail]>; Fri, 27 Jun 2003 02:43:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5R9hEBl022861 for ietf-smime-bks; Fri, 27 Jun 2003 02:43:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R9hCrb022856 for <[e-mail]>; Fri, 27 Jun 2003 02:43:13 -0700 (PDT) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 1FD6F122339; Fri, 27 Jun 2003 10:43:12 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256D52.003AE762 ; Fri, 27 Jun 2003 10:43:23 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Julien Stern" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 27 Jun 2003 10:43:02 +0000
Subject: Re: (Practical) S/MIME certificate chain handling
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>

> While I might have overlooked an option which actually allows the
> sending of a full chain, do you think it would be reasonable, and
> in the scope and the spirit of the S/MIME Working Group, to mandate
> that client MUST(?)/SHOULD(?) have an option that sends all information
> available to validate the sender cert (cert chain + possibly crl and/or OCSP).

This behaviour came out as a Best Practice recommendation from the
analysis of the results for the recent EEMA PKI Challenge project.

Chris
Royal Mail is a trading name of Royal Mail Group plc. Registered in England and
Wales.
Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEQqrb051535 for <[e-mail]>; Thu, 26 Jun 2003 07:26:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5QEQqoU051534 for ietf-smime-bks; Thu, 26 Jun 2003 07:26:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEQprb051528 for <[e-mail]>; Thu, 26 Jun 2003 07:26:51 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 7310B40E5C for <[e-mail]>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 8CE4B4462 for <[e-mail]>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08899-06 for <[e-mail]>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 513F74453 for <[e-mail]>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 26 Jun 2003 16:26:46 +0200
From: "Julien Stern" <[e-mail]>
Date: Thu, 26 Jun 2003 16:26:46 +0200
To: [e-mail]
Subject: (Practical) S/MIME certificate chain handling
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at example.com
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 all,

I have a question regarding certificate chain verification when
receiving a signed email.

rfc2632bis-03.txt says that

  "A receiving agent needs to provide some certificate retrieval
  mechanism in order to gain access to certificates for recipients of
  digital envelopes."

And then explains that X.500 (or LDAP) directories could be used,
or maybe the DNS system, or that the certificates could be transmitted
in the mail.

In the (very) long run, directories of some kind (where both
certificates and crl could be checked), or a remote chain verification
server as investigated by PKIX, seem to be nice solutions.

However, nowadays, such systems are highly manual at best, and totally
inexistent in most cases, hence, it would seem reasonnable to provide
the full chain of certificates needed to verify the sender's one(s), as
suggested by CMS (RFC2632) :

  "certificates is a collection of certificates. It is intended that the
  set of certificates be sufficient to contain chains from a recognized
  "root" or "top-level certification authority" to all of the signers in
  the signerInfos field. There may be more certificates than necessary,
  and there may be certificates sufficient to contain chains from two or
  more independent top- level certification authorities. There may also
  be fewer certificates than necessary, if it is expected that recipients
  have an alternate means of obtaining necessary certificates (e.g., from
  a previous set of certificates)."


This fairly natural behavior is implemented in Outlook Express,
Netscape, Mozilla, Notes, OpenSSL, etc. Oddly enough, Outlook seem to
only send the sender certificate, and does not seem to provide a way
to send the full chain, making it quite unusable in practice for
secure email.

While I might have overlooked an option which actually allows the
sending of a full chain, do you think it would be reasonnable, and
in the scope and the spirit of the S/MIME Working Group, to mandate
that client MUST(?)/SHOULD(?) have an option that sends all information
available to validate the sender cert (cert chain + possibly crl and/or OCSP).

This option, especially if mandatory, would be of great use to
facilitate the widespread adoption of S/MIME, and could be deactivated
for efficiency reasons when directories (or a similar alternate system)
are widely deployed.

Thanks for your time.
Sincerely,

--
Julien Stern


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P8Igrb038321 for <[e-mail]>; Wed, 25 Jun 2003 01:18:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5P8IgG8038320 for ietf-smime-bks; Wed, 25 Jun 2003 01:18:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moorabbin.nexor.co.uk ([193.63.53.250]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P8HUrb037979 for <[e-mail]>; Wed, 25 Jun 2003 01:18:36 -0700 (PDT) (envelope-from [e-mail])
Received: from typhoon (actually host 210.53.63.193.in-addr.arpa) by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Wed, 25 Jun 2003 08:38:27 +0100
Reply-To: "g.lunt" <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Sean P. Turner'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Signed Receipts and Mail Lists
Date: Wed, 25 Jun 2003 08:40:05 +0100
Organization: Nexor
Message-ID: <001101c33aec$fee550c0$[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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
X-Spam-Status: No, hits=-100.2 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, USER_IN_WHITELIST version=2.43
X-Spam-Level: 
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,
 
> I'm not sure that the MLA returns a receipt on behalf of the
> ML members. 

OK - if an MLA should not return signed receipts then there is not a
problem with my scenario. 

> I looked through ESS again and I couldn't find anything that
> said if a  message enters an MLA with a signed receipt request that it

> shouldn't or should return a receipt.    

Is an MLA considered a "receiving agent"/"receiving
software"/"processing software" in section 2.3 of ESS? I had assumed
that it was but agree it is unclear.

> Typically (I think), originators want to know that the final recipient
got 
> the message not whether the MLA got it.

I think there are arguments for both. If an originator sends a message
to:

[e-mail]

the originator probably only wants to know that it got to the complaints
department at bigbank. The originator doesn't want to know (and bigbank
doesn't want to let the originator know) which individuals within
bigbank read the message.

> Then again maybe I didn't understand your scenario.

I don't think the originator needs to understand if the addresses they
are requesting signed receipts from are address lists or not. If an
originator sends a message to two recipients - one a mail list, one an
individual - and requests first tier signed receipts, they will never
receive a signed receipt from the mail list recipient. The user may find
this unexpected. Correlation software *may* be able to detect a mail
list recipient and handle it appropriately.


Graeme




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OM4Vrb095470 for <[e-mail]>; Tue, 24 Jun 2003 15:04:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OM4VGU095469 for ietf-smime-bks; Tue, 24 Jun 2003 15:04:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OM4Urb095461 for <[e-mail]>; Tue, 24 Jun 2003 15:04:30 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Tue, 24 Jun 2003 15:04:27 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>
Subject: Working on the agenda
Date: Tue, 24 Jun 2003 15:04:27 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAuqh8gIOXyEGTAn5b4A/[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.2800.1165
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>

Sean and I are working on the agenda for the WG meeting in Austria.  The
S/MIME WG timeslot appears to be:

TUESDAY, July 15, 2003
1300-1400 Afternoon Sessions I
SEC	smime	 S/MIME Mail Security WG

We are planning to finalize the agenda by Wednesday next week (July 2),
so please let us know if you'd like a slot.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLkIrb094953 for <[e-mail]>; Tue, 24 Jun 2003 14:46:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OLkHaE094951 for ietf-smime-bks; Tue, 24 Jun 2003 14:46:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLkHrb094942 for <[e-mail]>; Tue, 24 Jun 2003 14:46:17 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Tue, 24 Jun 2003 14:46:13 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: "'Rohan Mahy'" <[e-mail]>, <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Tue, 24 Jun 2003 14:46:13 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAgMw3iu/[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.2800.1165
Importance: Normal
In-Reply-To: <000201c33a96$6bd914c0$[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>

> -----Original Message-----
> From: Bonatti, Chris [mailto:[e-mail]] 
> Sent: Tuesday, June 24, 2003 2:20 PM
> To: 'Blake Ramsdell'
> Cc: 'Rohan Mahy'; [e-mail]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
>   I agree completely that the profile should continue to be 
> restricted.
> I also agree that it makes sense to poll the APPS folks.  Sounds like
> we're pretty much on the same wavelength.

OK, I'm writing it up in the latest draft, which I'll submit today or
tomorrow.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLKJrb094126 for <[e-mail]>; Tue, 24 Jun 2003 14:20:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OLKJts094125 for ietf-smime-bks; Tue, 24 Jun 2003 14:20:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5OLKJrb094120 for <[e-mail]>; Tue, 24 Jun 2003 14:20:19 -0700 (PDT) (envelope-from [e-mail])
Received: from pcp833894pcs.nrockv01.md.comcast.net (HELO OMNI) ([e-mail]@68.50.112.83 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 24 Jun 2003 21:20:21 -0000
Reply-To: <[e-mail]>
From: "Bonatti, Chris" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: "'Rohan Mahy'" <[e-mail]>, <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Tue, 24 Jun 2003 17:20:21 -0400
Organization: IECA, Inc.
Message-ID: <000201c33a96$6bd914c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5OLKJrb094121
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>

Blake,

  I agree completely that the profile should continue to be restricted.
I also agree that it makes sense to poll the APPS folks.  Sounds like
we're pretty much on the same wavelength.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Blake Ramsdell
Sent: Friday, June 20, 2003 18:13
To: [e-mail]
Cc: 'Rohan Mahy'; [e-mail]
Subject: RE: proposed addition to application/pkcs7-mime smime parameter



> -----Original Message---- 
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bonatti, Chris
> Sent: Friday, June 20, 2003 11:23 AM
> To: 'Blake Ramsdell'
> Cc: 'Rohan Mahy'; [e-mail]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
>   To me, this makes sense.  Even if it isn't required in an S/MIME 
> message, it stands to reason that other CMS wrappers might be used.  
> We don't actually prohibit their use in S/MIME do we?

2.4 of rfc2633bis says "only the Data, SignedData, EnvelopedData and
CompressedData content types are currently used for S/MIME."  These
types are deliberately constrained.

If we define all of the possible CMS types for the smime-type parameter
for application/pkcs7-mime, I don't want it to imply that they are all
allowable for this profile, which is currently not the case, and I don't
think it should be the case in the future.  It's my opinion that the
profile should be deliberately constrained to support a reasonable
subset of CMS types to support the application at hand, which I consider
to be primarily email, and to give some hope of creating a conforming
implementation.

We've got a specification that says that it is for using CMS with MIME
entities.  If we add in all of the known CMS types, we need to be clear
about their acceptable use in this profile, and that their definition in
the profile is informational only, and future profiles (such as the SIP
profile) may allow some of these constructs.  This falls somewhat into
the category of Paul's suggestion to include the micalg parameters for
sha-256 and sha-512, where they might be defined in the spec, but there
is no requirement that they be implemented.

And then we get into issues with messages that conform to the SIP
profile commingling with messages that conform to the MSG profile, and
what should happen there, if the SIP messages use types not allowed in
MSG (specifically AuthenticatedData).

I am leaning towards creating smime-type values that correspond to the
other CMS types, but APPS people might stand up and give an opinion, or
we might take it upon ourselves to find APPS folks (I think Rohan
suggested this) to weigh in.

Blake




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OIjErb085415 for <[e-mail]>; Tue, 24 Jun 2003 11:45:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OIjEJl085414 for ietf-smime-bks; Tue, 24 Jun 2003 11:45:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5OIiurb085400 for <[e-mail]>; Tue, 24 Jun 2003 11:44:56 -0700 (PDT) (envelope-from [e-mail])
Received: from 1cust58.tnt1.manassas.va.da.uu.net (HELO ieca.com) ([e-mail]@67.201.101.58 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 24 Jun 2003 18:44:57 -0000
Message-ID: <[e-mail]>
Date: Tue, 24 Jun 2003 14:35:55 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "g.lunt" <[e-mail]>
CC: ietf-smime <[e-mail]>
Subject: Re: Signed Receipts and Mail Lists
References: <001301c33a56$13ca7660$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Graeme,

I'm not sure that the MLA returns a receipt on behalf of the ML members. 
 I looked through ESS again and I couldn't find anything that said if a 
message enters an MLA with a signed receipt request that it shouldn't or 
should return a receipt.    Typically (I think), originators want to 
know that the final recipient got the message not whether the MLA got it.

Then again maybe I didn't understand your scenario.

spt

Graeme Lunt wrote:

>Hi,
>
>We have recently encountered an issue when trying to correlate signed
>receipts when using mail lists.
>
>Issue:
>
>When a MLA supports multiple lists using a single public/private key
>pair, it appears that there is insufficient information within a signed
>receipt generated by the MLA to determine to which recipient the signed
>receipt relates. 
>
>Take the case where a message is sent to two recipients, R1 and R2, and
>the user makes an "all" signed receipt request.
>
>R1 is actually a Mail List supported by an MLA using a single
>public/private key pair, MLA1.
>
>MLA1 receives the message for R1, expands the list, and sends a signed
>receipt "on behalf of" R1 back to the originator.
>
>The originator can identify the message to which the signed receipt
>relates (from the signedContentIdentifier) but not the recipient as the
>signature on the receipt is from MLA1. There is no way to relate this
>receipt to either R1 or R2.
>
>Possible resolution:
>
>One way to resolve this problem would be to add an extension to the
>Receipt syntax to include
>
>   ....
>   receiptFrom GeneralNames OPTIONAL
>}
>
>This field would allow the indication of whom the signed receipt was
>sent from and consequently correlation with the original recipient list.
>This also allows other scenarios where a third party may acknowledge
>receipt for a given recipient for example an assistant reading a
>managers mail. 
>
>This functionality is comparable to that of the "IPM Intended Recipient"
>field of an X.400 IPN.
>
>Also, if considering changing the Receipt structure it may be worthwhile
>adding an extension bucket at the same time (or even to support
>receiptFrom).
>
>Am I missing something?
>
>Graeme
>
>
>  
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OEkFrb068591 for <[e-mail]>; Tue, 24 Jun 2003 07:46:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OEkFtu068590 for ietf-smime-bks; Tue, 24 Jun 2003 07:46:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OEkErb068567; Tue, 24 Jun 2003 07:46:14 -0700 (PDT) (envelope-from [e-mail])
Received: from typhoon (actually host 210.53.63.193.in-addr.arpa) by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Tue, 24 Jun 2003 14:38:08 +0100
Reply-To: "g.lunt" <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: Signed Receipts and Mail Lists
Date: Tue, 24 Jun 2003 14:39:46 +0100
Organization: Nexor
Message-ID: <001301c33a56$13ca7660$[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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Status: No, hits=-99.4 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01,USER_IN_WHITELIST version=2.43
X-Spam-Level: 
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,

We have recently encountered an issue when trying to correlate signed
receipts when using mail lists.

Issue:

When a MLA supports multiple lists using a single public/private key
pair, it appears that there is insufficient information within a signed
receipt generated by the MLA to determine to which recipient the signed
receipt relates. 

Take the case where a message is sent to two recipients, R1 and R2, and
the user makes an "all" signed receipt request.

R1 is actually a Mail List supported by an MLA using a single
public/private key pair, MLA1.

MLA1 receives the message for R1, expands the list, and sends a signed
receipt "on behalf of" R1 back to the originator.

The originator can identify the message to which the signed receipt
relates (from the signedContentIdentifier) but not the recipient as the
signature on the receipt is from MLA1. There is no way to relate this
receipt to either R1 or R2.

Possible resolution:

One way to resolve this problem would be to add an extension to the
Receipt syntax to include

   ....
   receiptFrom GeneralNames OPTIONAL
}

This field would allow the indication of whom the signed receipt was
sent from and consequently correlation with the original recipient list.
This also allows other scenarios where a third party may acknowledge
receipt for a given recipient for example an assistant reading a
managers mail. 

This functionality is comparable to that of the "IPM Intended Recipient"
field of an X.400 IPN.

Also, if considering changing the Receipt structure it may be worthwhile
adding an extension bucket at the same time (or even to support
receiptFrom).

Am I missing something?

Graeme




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJjlrb077218 for <[e-mail]>; Mon, 23 Jun 2003 12:45:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NJjlNF077216 for ietf-smime-bks; Mon, 23 Jun 2003 12:45:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5NJjkrb077210 for <[e-mail]>; Mon, 23 Jun 2003 12:45:46 -0700 (PDT) (envelope-from [e-mail])
Received: from 1cust140.tnt1.manassas.va.da.uu.net (HELO ieca.com) ([e-mail]@67.201.101.140 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 23 Jun 2003 19:45:47 -0000
Message-ID: <[e-mail]>
Date: Mon, 23 Jun 2003 15:35:47 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Ietf-Smime <[e-mail]>
Subject: Re: MLA Expansion History processing questions
References: <003d01c32d3b$d8aea370$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Jim,

Comments in line.

Jim Schaad wrote:

>Consider the following message  S1(S2(M)).  
>
>1. S1 contains a two different SignerInfos.  SignerInfo #1 cannot be
>validated and contains an MLA Expansion history element.  SignerInfo #2
>can be validated.  Does the MLA stop processing of the message?  This is
>the case if there were two different MLA Expansion history elements, but
>this case is not explicity addressed.
>  
>
Hmm ... yes.

>2.  S1 validates and contains an MLA Expansion history element.  S2
>fails validation.  Since the MLA could in theory just evaluate S1 and
>not look at S2, is it considered to be illeagle behavior (i.e. MUST stop
>processing) to pass on this message?
>  
>
I thought it had to check for attributes especially ESSSecurityLabel 
prior to passing it on.  I think it ought to fail.  S2 could be just be 
gobledegook and you don't want to pass that on.

>Jim
>
>  
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJjirb077208 for <[e-mail]>; Mon, 23 Jun 2003 12:45:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NJjirZ077207 for ietf-smime-bks; Mon, 23 Jun 2003 12:45:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5NJjgrb077201 for <[e-mail]>; Mon, 23 Jun 2003 12:45:42 -0700 (PDT) (envelope-from [e-mail])
Received: from 1cust140.tnt1.manassas.va.da.uu.net (HELO ieca.com) ([e-mail]@67.201.101.140 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 23 Jun 2003 19:45:43 -0000
Message-ID: <[e-mail]>
Date: Mon, 23 Jun 2003 15:32:16 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Ietf-Smime <[e-mail]>
Subject: Re: MLA Processing Questions
References: <003e01c32d43$70732940$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Jim,

Comments in line.

Jim Schaad wrote:

>A couple of additional questions for consideration.
>
>1.  Consider the message S1(S2(S3(M))) where S2 has an
>MLExpansionHistory attribute and S1 has a ESSSecurityLabel attribute.
>Under the current processing rules the security label would not be on
>the output message of an MLA.  Attributes on S2 are preserved, but not
>those on S1.  Does this need to be changed?
>  
>
I went back and forth on this one.  I can see why you want to keep a 
label, but I think you ought to only retain it if you actually track who 
applied it.  But, that's going to get really complicated so I'd say that 
you should not preserve the label in s1.

>2.  Are there any other attributes for which this needs to be changed as
>well?
>  
>
Not sure off the top of my head.

>3.  If you have the message S1(S2(E1(S3(M)))), if S1 or S2 contains an
>ESSSecurityLabel attribute it would be preserved only if there was an
>MLExpansionHistory attribute in the same signature layer.
>  
>
Yes I think that's right.

>4.  Are there any other attributes that need to be preserved here as
>well.
>
>5.  There is a rule that states all attributes need to be kept unless
>replaced.  This needs to be modified to exclude the
>id-aa-SigningCertificate attribute.  If this element is not replaced but
>copied then the signature of the MLA SHOULD fail validation.  Can
>anybody else think of attributes for which this is also true.
>
>Jim
>
>  
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJjfrb077199 for <[e-mail]>; Mon, 23 Jun 2003 12:45:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NJjf4D077198 for ietf-smime-bks; Mon, 23 Jun 2003 12:45:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5NJjdrb077192 for <[e-mail]>; Mon, 23 Jun 2003 12:45:39 -0700 (PDT) (envelope-from [e-mail])
Received: from 1cust140.tnt1.manassas.va.da.uu.net (HELO ieca.com) ([e-mail]@67.201.101.140 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 23 Jun 2003 19:45:40 -0000
Message-ID: <[e-mail]>
Date: Mon, 23 Jun 2003 14:49:01 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Ietf-Smime <[e-mail]>
Subject: Re: Receipt Request Processing Questions
References: <003901c32d2d$fb071730$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Jim,

Thoughts in line.

Jim Schaad wrote:

 >The following do not appear to be well address in the present ESS
 >document.
 >
 >1.  For the message S1(S2(M)) - If S2 validates and contains a receipt
 >request but S1 fails to validate.  Should the receipt be generated?
 >
 >
Yes I think it should.  The layer with the signed content identifier and
the receipt request is verifiable so one should be returned.

 >2.  For the message S1(S2(M)) - If S2 validates and contains a receipt
 >request, S1 contains an MLExpansionHistory attribute, but cannot be
 >validate due to either a) missing certificate or b) unknown signing
 >algorithm.  Should a) the receipt be generated and b) the
 >MLExpansionHistory attribute be obeyed?
 >
 >
For a - yes
For b - no

 >3.  The following is a "new" case  S1(E1(?)) - S1 contains a receipt
 >request, E1 cannot be decrypted due to the lack of a lock box for the
 >receipient.  Should a receipt be generated?
 >
 >
Yes I think it should.  It's only telling the originator that the
message was received not that they could open it.  If the recipient
can't open it they should send a message indicating as much.

 >Jim
 >
 >
 >






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJjbrb077190 for <[e-mail]>; Mon, 23 Jun 2003 12:45:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NJjbPw077189 for ietf-smime-bks; Mon, 23 Jun 2003 12:45:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5NJjarb077184 for <[e-mail]>; Mon, 23 Jun 2003 12:45:36 -0700 (PDT) (envelope-from [e-mail])
Received: from 1cust140.tnt1.manassas.va.da.uu.net (HELO ieca.com) ([e-mail]@67.201.101.140 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 23 Jun 2003 19:45:37 -0000
Message-ID: <[e-mail]>
Date: Mon, 23 Jun 2003 14:47:12 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Ietf-Smime <[e-mail]>
Subject: Re: Receipt Processing Behavior
References: <003c01c32d37$672e61d0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Jim,

I'd say yes.  If I send to an MLA which then sends to you and then you 
send it to Russ and ask for a reciept ... you ought to get one.

spt

Jim Schaad wrote:

 >What is the correct behavior for the following?   I can see different
 >arguments.
 >
 >Consider the following S1(S2(S3(M))) where
 >
 >S3 contains a receipt request
 >S2 contains an MLExpansionHistory (now a ReceiptPolicy attribute) which
 >says NONE
 >S3 contains a ReceiptPolicy attribute which says - add
 >[e-mail]
 >
 >Should the receipt be created or not?
 >
 >jim
 >
 >
 >






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMNlrb005172 for <[e-mail]>; Fri, 20 Jun 2003 15:23:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KMNkHB005171 for ietf-smime-bks; Fri, 20 Jun 2003 15:23:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMNkrb005162 for <[e-mail]>; Fri, 20 Jun 2003 15:23:46 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 20 Jun 2003 15:23:43 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Rohan Mahy'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 20 Jun 2003 15:23:42 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Rohan Mahy
> Sent: Thursday, June 19, 2003 5:14 PM
> To: Blake Ramsdell
> Cc: [e-mail]
> Subject: Re: proposed addition to application/pkcs7-mime 
> smime parameter
> 
> - we are not restricted to out MIME bodies being 7-bit... they can be 
> binary, but they are still MIME.  I still need to have insure that my 
> --boundaries don't appear in my content for example.

I believe that the latest rfc2633bis spec in section 3.1.2 addresses
this.  The bottom line is that binary is OK, but you should negotiate a
preference if you can.

> - we can use attached signatures. since we have a negotiation 
> mechanism, if the UAS doesn't understand application/pkcs7-mime, its 
> can send a repairable error response (hey! I can't read this content 
> format) and the UAC will either send a different MIME type or give up.

I'm not sure why the language is so soft about attached signatures
(SHOULD support both clear signed and opaque signed).  In any case, in
practice I am not aware of a receiving client that can't interpret
application/pkcs7-mime opaque SignedData objects.

> - because some pairs of SIP entities already have shared secrets 
> (because of their digest legacy), we would like to used 
> AuthenticatedData instead of SignedData in some cases.  If email 
> clients already had shared secrets, you might have done that in email 
> too, so there is really nothing special about this.

This is the one that's going to cause me kidney pain.  Basically, a
profile for CMS or even a profile for MSG is meant to constrain the
amount of stuff you have to implement.  So if SIP is a profile of MSG
(which seems reasonable), how likely is it that SIP objects are going to
end up hanging out with "base" MSG objects?

> I don't think any of these things change the semantics of the 
> MIME type.

I agree.  I forgot that you had already said that SIP used MIME objects,
so my earlier comments about "raw" CMS objects are not relevant.

> I'll ping some friends who are active in the APPS Area as well, but I 
> don't think I am too out of line here.

I think that we are indeed running into APPS-type concerns here.

As far as the best way to proceed, I am thinking that SIP ends up being
a profile of MSG, MSG defines the smime-type parameters as you have
suggested, but MSG does will not add any MUST/SHOULD recommendations
about other CMS types.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMCrrb004765 for <[e-mail]>; Fri, 20 Jun 2003 15:12:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KMCqbl004764 for ietf-smime-bks; Fri, 20 Jun 2003 15:12:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMCqrb004757 for <[e-mail]>; Fri, 20 Jun 2003 15:12:52 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Fri, 20 Jun 2003 15:12:49 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: "'Rohan Mahy'" <[e-mail]>, <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 20 Jun 2003 15:12:48 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
Importance: Normal
In-Reply-To: <003a01c33759$01dd8e60$[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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Bonatti, Chris
> Sent: Friday, June 20, 2003 11:23 AM
> To: 'Blake Ramsdell'
> Cc: 'Rohan Mahy'; [e-mail]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
>   To me, this makes sense.  Even if it isn't required in an S/MIME
> message, it stands to reason that other CMS wrappers might be 
> used.  We
> don't actually prohibit their use in S/MIME do we?

2.4 of rfc2633bis says "only the Data, SignedData, EnvelopedData and
CompressedData content types are currently used for S/MIME."  These
types are deliberately constrained.

If we define all of the possible CMS types for the smime-type parameter
for application/pkcs7-mime, I don't want it to imply that they are all
allowable for this profile, which is currently not the case, and I don't
think it should be the case in the future.  It's my opinion that the
profile should be deliberately constrained to support a reasonable
subset of CMS types to support the application at hand, which I consider
to be primarily email, and to give some hope of creating a conforming
implementation.

We've got a specification that says that it is for using CMS with MIME
entities.  If we add in all of the known CMS types, we need to be clear
about their acceptable use in this profile, and that their definition in
the profile is informational only, and future profiles (such as the SIP
profile) may allow some of these constructs.  This falls somewhat into
the category of Paul's suggestion to include the micalg parameters for
sha-256 and sha-512, where they might be defined in the spec, but there
is no requirement that they be implemented.

And then we get into issues with messages that conform to the SIP
profile commingling with messages that conform to the MSG profile, and
what should happen there, if the SIP messages use types not allowed in
MSG (specifically AuthenticatedData).

I am leaning towards creating smime-type values that correspond to the
other CMS types, but APPS people might stand up and give an opinion, or
we might take it upon ourselves to find APPS folks (I think Rohan
suggested this) to weigh in.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KINBrb093900 for <[e-mail]>; Fri, 20 Jun 2003 11:23:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KINBYq093899 for ietf-smime-bks; Fri, 20 Jun 2003 11:23:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5KINBrb093893 for <[e-mail]>; Fri, 20 Jun 2003 11:23:11 -0700 (PDT) (envelope-from [e-mail])
Received: from pcp833894pcs.nrockv01.md.comcast.net (HELO OMNI) ([e-mail]@68.50.112.83 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 20 Jun 2003 18:23:12 -0000
Reply-To: <[e-mail]>
From: "Bonatti, Chris" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: "'Rohan Mahy'" <[e-mail]>, <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 20 Jun 2003 14:23:10 -0400
Organization: IECA, Inc.
Message-ID: <003a01c33759$01dd8e60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5KINBrb093894
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>

Blake,

  To me, this makes sense.  Even if it isn't required in an S/MIME
message, it stands to reason that other CMS wrappers might be used.  We
don't actually prohibit their use in S/MIME do we?

  I'm wondering if this is starting to look like misplaced text.
Originally, it made sense to have MIME types in the message spec, but
now we also have them in the X.400 transport spec, and apparantly some
that don't fit neatly anywhere.  Maybe this should have been rolled back
into CMS.  (I know it's too late for that.)  Short of that perhaps the
best strategy is to repeat the whole list everywhere that it appears.

Regards,
Chris


On Thursday, June 19, 2003, at 8:14 PM, Rohan Mahy wrote:

> 
> On Thursday, June 19, 2003, at 03:50 PM, Blake Ramsdell wrote:
> 
> >> -----Original Message-----
> >> From: [e-mail] 
> >> [mailto:[e-mail]] On Behalf Of Rohan Mahy
> >> Sent: Friday, June 06, 2003 7:59 PM
> >> To: Blake Ramsdell
> >> Cc: [e-mail]; [e-mail]
> >> Subject: proposed addition to application/pkcs7-mime smime 
> parameter
> >>
> >> I have included some proposed text to add the other CMS 
> types to the 
> >> smime-type mime parameter.  Alternatively a new cms-type mime 
> >> parameter could be defined, but this seems a but pedantic to me.
> >
> > We are in a strange situation here, and I'd like to get feedback on 
> > this.  One side of me says that the "application/pkcs7-mime" means 
> > "MIME packaged in PKCS #7 (which then became CMS) for the 
> purpose of 
> > moving around secured MIME entities".  I don't know if it's 
> a better 
> > idea to
> > a)
> > overload the application/pkcs7-mime type to mean "CMS, possibly not 
> > wrapped in MIME", or b) introduce application/cms in a 
> separate draft, 
> > along with a cms-type parameter that explains the inner type.
> 
> I'm not sure what you mean "not wrapped in MIME" here.  In 
> all the SIP 
> cases at least, we are always talking about taking some MIME content, 
> performing some CMS operation on it, and putting the 
> resulting CMS blob 
> in a MIME body.  There are only three things different here:
> 
> - we are not restricted to out MIME bodies being 7-bit... they can be 
> binary, but they are still MIME.  I still need to have insure that my 
> --boundaries don't appear in my content for example.
> 
> - we can use attached signatures. since we have a negotiation 
> mechanism, if the UAS doesn't understand application/pkcs7-mime, its 
> can send a repairable error response (hey! I can't read this content 
> format) and the UAC will either send a different MIME type or give up.
> 
> - because some pairs of SIP entities already have shared secrets 
> (because of their digest legacy), we would like to used 
> AuthenticatedData instead of SignedData in some cases.  If email 
> clients already had shared secrets, you might have done that in email 
> too, so there is really nothing special about this.
> 
> I don't think any of these things change the semantics of the 
> MIME type.
> 
> I'll ping some friends who are active in the APPS Area as well, but I 
> don't think I am too out of line here.
> 
> thanks,
> -rohan
> 
> 
> 
> > I know that there was much discussion about application/xml in a
> > similar
> > context, and I don't know if there's anything we can learn 
> from that in
> > order to resolve this.  It seems that the application/xml semantic 
> > would
> > be very similar to the application/cms semantic, but I may not
> > understand it correctly.
> >
> > I'm going to release 2633bis-05 shortly, and if there's no 
> discussion
> > on
> > this topic I'm not going to include anything in that draft.  If it's
> > important, we should work through it.
> >
> > Blake
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K0D7rb010231 for <[e-mail]>; Thu, 19 Jun 2003 17:13:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5K0D7X2010230 for ietf-smime-bks; Thu, 19 Jun 2003 17:13:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K0D5rb010223 for <[e-mail]>; Thu, 19 Jun 2003 17:13:05 -0700 (PDT) (envelope-from [e-mail])
Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2003 17:15:47 -0800
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5K0D1EP027153; Thu, 19 Jun 2003 17:13:01 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH99276; Thu, 19 Jun 2003 17:06:50 -0700 (PDT)
Date: Thu, 19 Jun 2003 17:14:10 -0700
Subject: Re: proposed addition to application/pkcs7-mime smime parameter
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>
From: Rohan Mahy <[e-mail]>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
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 Thursday, June 19, 2003, at 03:50 PM, Blake Ramsdell wrote:

>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Rohan Mahy
>> Sent: Friday, June 06, 2003 7:59 PM
>> To: Blake Ramsdell
>> Cc: [e-mail]; [e-mail]
>> Subject: proposed addition to application/pkcs7-mime smime parameter
>>
>> I have included some proposed text to add the other CMS types to the
>> smime-type mime parameter.  Alternatively a new cms-type mime
>> parameter
>> could be defined, but this seems a but pedantic to me.
>
> We are in a strange situation here, and I'd like to get feedback on
> this.  One side of me says that the "application/pkcs7-mime" means 
> "MIME
> packaged in PKCS #7 (which then became CMS) for the purpose of moving
> around secured MIME entities".  I don't know if it's a better idea to 
> a)
> overload the application/pkcs7-mime type to mean "CMS, possibly not
> wrapped in MIME", or b) introduce application/cms in a separate draft,
> along with a cms-type parameter that explains the inner type.

I'm not sure what you mean "not wrapped in MIME" here.  In all the SIP 
cases at least, we are always talking about taking some MIME content, 
performing some CMS operation on it, and putting the resulting CMS blob 
in a MIME body.  There are only three things different here:

- we are not restricted to out MIME bodies being 7-bit... they can be 
binary, but they are still MIME.  I still need to have insure that my 
--boundaries don't appear in my content for example.

- we can use attached signatures. since we have a negotiation 
mechanism, if the UAS doesn't understand application/pkcs7-mime, its 
can send a repairable error response (hey! I can't read this content 
format) and the UAC will either send a different MIME type or give up.

- because some pairs of SIP entities already have shared secrets 
(because of their digest legacy), we would like to used 
AuthenticatedData instead of SignedData in some cases.  If email 
clients already had shared secrets, you might have done that in email 
too, so there is really nothing special about this.

I don't think any of these things change the semantics of the MIME type.

I'll ping some friends who are active in the APPS Area as well, but I 
don't think I am too out of line here.

thanks,
-rohan



> I know that there was much discussion about application/xml in a 
> similar
> context, and I don't know if there's anything we can learn from that in
> order to resolve this.  It seems that the application/xml semantic 
> would
> be very similar to the application/cms semantic, but I may not
> understand it correctly.
>
> I'm going to release 2633bis-05 shortly, and if there's no discussion 
> on
> this topic I'm not going to include anything in that draft.  If it's
> important, we should work through it.
>
> Blake


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JMoirb007151 for <[e-mail]>; Thu, 19 Jun 2003 15:50:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JMoiCu007150 for ietf-smime-bks; Thu, 19 Jun 2003 15:50:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JMohrb007097 for <[e-mail]>; Thu, 19 Jun 2003 15:50:43 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 19 Jun 2003 15:50:40 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Rohan Mahy'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Thu, 19 Jun 2003 15:50:40 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Rohan Mahy
> Sent: Friday, June 06, 2003 7:59 PM
> To: Blake Ramsdell
> Cc: [e-mail]; [e-mail]
> Subject: proposed addition to application/pkcs7-mime smime parameter
> 
> I have included some proposed text to add the other CMS types to the 
> smime-type mime parameter.  Alternatively a new cms-type mime 
> parameter 
> could be defined, but this seems a but pedantic to me.

We are in a strange situation here, and I'd like to get feedback on
this.  One side of me says that the "application/pkcs7-mime" means "MIME
packaged in PKCS #7 (which then became CMS) for the purpose of moving
around secured MIME entities".  I don't know if it's a better idea to a)
overload the application/pkcs7-mime type to mean "CMS, possibly not
wrapped in MIME", or b) introduce application/cms in a separate draft,
along with a cms-type parameter that explains the inner type.

I know that there was much discussion about application/xml in a similar
context, and I don't know if there's anything we can learn from that in
order to resolve this.  It seems that the application/xml semantic would
be very similar to the application/cms semantic, but I may not
understand it correctly.

I'm going to release 2633bis-05 shortly, and if there's no discussion on
this topic I'm not going to include anything in that draft.  If it's
important, we should work through it.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JMgurb006759 for <[e-mail]>; Thu, 19 Jun 2003 15:42:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JMguXM006758 for ietf-smime-bks; Thu, 19 Jun 2003 15:42:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JMgtrb006748 for <[e-mail]>; Thu, 19 Jun 2003 15:42:55 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 19 Jun 2003 15:42:52 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Date: Thu, 19 Jun 2003 15:42:52 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ Housley
> Sent: Thursday, June 19, 2003 10:27 AM
> To: Blake Ramsdell
> Cc: [e-mail]
> Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
> 
> Thank you for making the comments that I requested when I reviewed
> draft-ietf-smime-rfc2633bis-03.
> 
> I support the addition of a SHOULD for support of AES in CBC mode.
> 
> I compiled the ASN.1 module without error.

OK, I am going to release -05 with the following changes:

1. Changes for id-dsa

2. Addition of AES for SHOULD

I will address the comments made by Rohan Mahy in a separate message.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JKmorb002490 for <[e-mail]>; Thu, 19 Jun 2003 13:48:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JKmo71002489 for ietf-smime-bks; Thu, 19 Jun 2003 13:48:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5JKmmrb002480 for <[e-mail]>; Thu, 19 Jun 2003 13:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 21682 invoked by uid 0); 19 Jun 2003 20:47:38 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.178.230) by woodstock.binhost.com with SMTP; 19 Jun 2003 20:47:38 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 19 Jun 2003 13:27:04 -0400
To: "Blake Ramsdell" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Cc: [e-mail]
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50S [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>

Blake:

Thank you for making the comments that I requested when I reviewed
draft-ietf-smime-rfc2633bis-03.

I support the addition of a SHOULD for support of AES in CBC mode.

I compiled the ASN.1 module without error.

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HIRrrb002762 for <[e-mail]>; Tue, 17 Jun 2003 11:27:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HIRrXi002761 for ietf-smime-bks; Tue, 17 Jun 2003 11:27:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5HIRqrb002756 for <[e-mail]>; Tue, 17 Jun 2003 11:27:52 -0700 (PDT) (envelope-from [e-mail])
Received: from pcp833894pcs.nrockv01.md.comcast.net (HELO OMNI) ([e-mail]@68.50.112.83 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Jun 2003 18:27:53 -0000
Reply-To: <[e-mail]>
From: "Bonatti, Chris" <[e-mail]>
To: "'Pandey, Arun'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Loss of Information while mapping an Internet S/MIME Message to X.400.
Date: Tue, 17 Jun 2003 14:27:50 -0400
Keywords: Revisit/Action
Organization: IECA, Inc.
Message-ID: <000001c334fe$2a784b10$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C334DC.A366AB10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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 a multi-part message in MIME format.

------=_NextPart_000_0001_01C334DC.A366AB10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Arun,
=20
   I don't think this is a problem of loss of information, because
whatever information is sent is received in the content.  In the
scenario you describe, I think it is likely that the content would be an
RFC 822 (2822?) message.  So provided that the recipient can decode such
content, all information that the sending client intended gets through
okay.  While I don't think most X.400 UAs today will decode RFC 822
there are some that will, and I strongly believe that we should support
that scenario for architectural reasons.
=20
   I would not be totally adverse to having a statement like those in
2633bis that says, "the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services to
these headers."  However, it should be noted that this adds no
requirements (it's only a MAY).  Also, I'm not sure where to place such
a statement in X.400 transport; it's kind of out of scope.
=20
   However, it is important to note that X.400 transport does not
REQUIRE that the innermost content be in the RFC 822 format.  That is
one reason that we don't want to make any strong associations to IPMS
content.  As the documents stand, three scenarios are supported:
=20
        - CMS protected X.400 content (not necessarily IPMS),
transferred over X.400
        - CMS protected X.400 content, transferred over SMTP
        - CMS protected RFC 822 content, transferred over X.400
        - CMS protected other (non-822 MIME or non-MIME content),
transferred over X.400
=20
   The problem here is that I think we want to say as little as possible
about content translation.  These drafts (and S/MIME in general)
fundamentally don't profess to provide translation, only secure
transfer.  Our scenario is that we assume that both the X.400 and SMTP
communities will agree to use a common content for interoperability
sake.  Hence the caveats in the 2nd and 3rd paragraphs of the
introduction.  Admittedly, this has caused a little friction in the
IESG, but in the end I think they agreed that this is the least painful
of several unattractive alternatives.  You can't have MIXER-style
translations AND end-to-end security.
=20
Regards,
Chris
=20
=20
=20
 -----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandey, Arun
Sent: Friday, June 06, 2003 07:33
To: [e-mail]
Subject: Loss of Information while mapping an Internet S/MIME Message to
X.400.



Hi,=20

As per draft-ietf-smime-x400transport-07.txt:=20
"When transporting a CMS-protected message in X.400, the preferred
approach is to=20
convey the object as X.400 message content. Implementations MUST include
the CMS=20
object in the content field of the X.400 message."=20

However when mapping an Internet S/MIME message to an X.400 Message:=20
1. The CMS object is placed in the X.400 Message Content (as
recommended).=20
2. The RFC 822 header fields of the Internet message that can be mapped
directly=20
   to the X.400 envelope fields are placed in the X.400 Message
Envelope.=20

3. This leaves out the Internet Message header fields that are normally
mapped to=20
   the IPM Content Heading fields. In the X.400 Content carrying the CMS
object=20
   there are no corresponding fields for them. As a result such fields
apparently=20
   cannot be mapped to the X.400 message and will be lost (on conversion
from=20
   Internet to X.400 message). Such fields are :=20
   Subject, From, To, Reply-to, In-reply-to, Message-id, cc, bcc,
Sender, Expiry-=20
   date, Deferred-delivery-date, Latest-delivery-time, Importance,
Sensitivity,=20
   Language and References.=20
  =20
How can this loss of information be avoided, what is the recommended way
around=20
this particular problem?=20

The possible workarounds could be:=20

1. The Internet User Agent constructing an S/MIME message SHOULD place
the=20
   message content along with these fields into a Message/rfc-822
content before=20
   securing it. This should be done if these fields are desired to be
seen by=20
   the receiving user agent (in case the message is to be transported
over an=20
   X.400 network.)=20

   But I found that existing applications like Microsoft Outlook do not
provide=20
   an option to perform an Message/rfc-822 wrapping of these fileds.=20

2. Another solution could be to map the CMS object in an IPMS content,
wherein=20
   the above fields could then be mapped to the IPMS content heading
fields, and=20
   the CMS object could be placed in an appropriate bodypart (ftbp with
file type=20
   as smime.p7m).=20
  =20
   But this goes against the recommendation "Implementations generally
SHOULD=20
   NOT embed CMS objects within X.400 body parts, but should instead
convey them=20
   as content as described in sec. 2.2" of
draft-ietf-smime-x400transport07.txt.=20

Best Regards=20
Arun Pandey=20


------=_NextPart_000_0001_01C334DC.A366AB10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>Arun,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>&nbsp;&nbsp; I don't think this is a problem =
of loss of=20
information, because whatever information is sent is received in the=20
content.&nbsp; In the scenario you describe, I think it is likely that =
the=20
content would be an RFC 822 (2822?) message.&nbsp; So provided that the=20
recipient can decode such content, all information that the sending =
client=20
intended gets through okay.&nbsp; While I don't think most X.400 UAs =
today will=20
decode RFC 822 there are some that will, and I strongly believe that we =
should=20
support that scenario for architectural reasons.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><SPAN class=3D697255316-17062003><FONT =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; I would not be totally adverse to having a =
statement like=20
those in 2633bis that says, "</FONT><FONT color=3D#0000ff size=3D2>the =
sending=20
client MAY wrap a full MIME message in a message/rfc822 wrapper in order =
to=20
apply S/MIME security services to these headers."&nbsp; However, it =
should be=20
noted that this adds no requirements (it's only a MAY).&nbsp; Also, I'm =
not sure=20
where to place such a statement in X.400 transport; it's kind of out of=20
scope.</FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>&nbsp;&nbsp; However, it is important to note =
that=20
X.400 transport does not REQUIRE that the innermost content be in the =
RFC 822=20
format.&nbsp; That is one reason that we don't want to make any strong=20
associations to&nbsp;IPMS content.&nbsp; As the documents stand, three =
scenarios=20
are supported:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
CMS=20
protected X.400 content (not necessarily IPMS), transferred over=20
X.400</SPAN></FONT></DIV><SPAN class=3D697255316-17062003>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
CMS=20
protected X.400 content, transferred over SMTP</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - CMS protected RFC =
822=20
content, transferred over X.400</FONT></DIV>
<DIV></SPAN><SPAN class=3D697255316-17062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - CMS protected =
other (non-822=20
MIME or non-MIME content), transferred over X.400</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>&nbsp;&nbsp; The problem here is that I think =
we want=20
to say as little as possible about content translation.&nbsp; These =
drafts (and=20
S/MIME in general) fundamentally don't profess to provide translation, =
only=20
secure transfer.&nbsp; Our scenario is that we assume that both the =
X.400 and=20
SMTP communities will agree to use a common content for interoperability =

sake.&nbsp; Hence the caveats in the 2nd and 3rd paragraphs of the=20
introduction.&nbsp; Admittedly, this has caused a little friction in the =
IESG,=20
but in the end I think they agreed that this is the least painful of =
several=20
unattractive alternatives.&nbsp; You can't have MIXER-style translations =
AND=20
end-to-end security.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003>Chris</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D697255316-17062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><SPAN =
class=3D697255316-17062003></SPAN></FONT><FONT=20
face=3DTahoma><FONT size=3D2><SPAN class=3D697255316-17062003><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D697255316-17062003>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
[e-mail] [mailto:[e-mail]] =
<B>On=20
Behalf Of </B>Pandey, Arun<BR><B>Sent:</B> Friday, June 06, 2003=20
07:33<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Loss of =
Information=20
while mapping an Internet S/MIME Message to =
X.400.<BR><BR></DIV></FONT></FONT>
<P><FONT size=3D2>Hi,</FONT> </P>
<P><FONT size=3D2>As per draft-ietf-smime-x400transport-07.txt:</FONT> =
<BR><FONT=20
size=3D2>"When transporting a CMS-protected message in X.400, the =
preferred=20
approach is to</FONT> <BR><FONT size=3D2>convey the object as X.400 =
message=20
content. Implementations MUST include the CMS </FONT><BR><FONT =
size=3D2>object in=20
the content field of the X.400 message."</FONT> </P>
<P><FONT size=3D2>However when mapping an Internet S/MIME message to an =
X.400=20
Message:</FONT> <BR><FONT size=3D2>1. The CMS object is placed in the =
X.400=20
Message Content (as recommended).</FONT> <BR><FONT size=3D2>2. The RFC =
822 header=20
fields of the Internet message that can be mapped directly =
</FONT><BR><FONT=20
size=3D2>&nbsp;&nbsp; to the X.400 envelope fields are placed in the =
X.400 Message=20
Envelope.</FONT> </P>
<P><FONT size=3D2>3. This leaves out the Internet Message header fields =
that are=20
normally mapped to </FONT><BR><FONT size=3D2>&nbsp;&nbsp; the IPM =
Content Heading=20
fields. In the X.400 Content carrying the CMS object </FONT><BR><FONT=20
size=3D2>&nbsp;&nbsp; there are no corresponding fields for them. As a =
result such=20
fields apparently </FONT><BR><FONT size=3D2>&nbsp;&nbsp; cannot be =
mapped to the=20
X.400 message and will be lost (on conversion from </FONT><BR><FONT=20
size=3D2>&nbsp;&nbsp; Internet to X.400 message). Such fields are =
:</FONT>=20
<BR><FONT size=3D2>&nbsp;&nbsp; Subject, From, To, Reply-to, =
In-reply-to,=20
Message-id, cc, bcc, Sender, Expiry-</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; date,=20
Deferred-delivery-date, Latest-delivery-time, Importance, Sensitivity,=20
</FONT><BR><FONT size=3D2>&nbsp;&nbsp; Language and References.</FONT> =
<BR><FONT=20
size=3D2>&nbsp;&nbsp; </FONT><BR><FONT size=3D2>How can this loss of =
information be=20
avoided, what is the recommended way around </FONT><BR><FONT =
size=3D2>this=20
particular problem?</FONT> </P>
<P><FONT size=3D2>The possible workarounds could be:</FONT> </P>
<P><FONT size=3D2>1. The Internet User Agent constructing an S/MIME =
message SHOULD=20
place the </FONT><BR><FONT size=3D2>&nbsp;&nbsp; message content along =
with these=20
fields into a Message/rfc-822 content before </FONT><BR><FONT=20
size=3D2>&nbsp;&nbsp; securing it. This should be done if these fields =
are desired=20
to be seen by </FONT><BR><FONT size=3D2>&nbsp;&nbsp; the receiving user =
agent (in=20
case the message is to be transported over an </FONT><BR><FONT=20
size=3D2>&nbsp;&nbsp; X.400 network.)</FONT> </P>
<P><FONT size=3D2>&nbsp;&nbsp; But I found that existing applications =
like=20
Microsoft Outlook do not provide </FONT><BR><FONT size=3D2>&nbsp;&nbsp; =
an option=20
to perform an Message/rfc-822 wrapping of these fileds.</FONT> </P>
<P><FONT size=3D2>2. Another solution could be to map the CMS object in =
an IPMS=20
content, wherein</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; the above fields =
could=20
then be mapped to the IPMS content heading fields, and </FONT><BR><FONT=20
size=3D2>&nbsp;&nbsp; the CMS object could be placed in an appropriate =
bodypart=20
(ftbp with file type </FONT><BR><FONT size=3D2>&nbsp;&nbsp; as =
smime.p7m).=20
</FONT><BR><FONT size=3D2>&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp; But=20
this goes against the recommendation "Implementations generally SHOULD=20
</FONT><BR><FONT size=3D2>&nbsp;&nbsp; NOT embed CMS objects within =
X.400 body=20
parts, but should instead convey them </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp; as=20
content as described in sec. 2.2" of=20
draft-ietf-smime-x400transport07.txt.</FONT> </P>
<P><FONT size=3D2>Best Regards</FONT> <BR><FONT size=3D2>Arun =
Pandey</FONT>=20
</P></BODY></HTML>

------=_NextPart_000_0001_01C334DC.A366AB10--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5F0igrb059729 for <[e-mail]>; Sat, 14 Jun 2003 17:44:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5F0ifkX059728 for ietf-smime-bks; Sat, 14 Jun 2003 17:44:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5F0ifrb059710; Sat, 14 Jun 2003 17:44:41 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Sat, 14 Jun 2003 17:44:38 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>
Subject: RE: Making AES a SHOULD in draft-ietf-smime-rfc2633bis?
Date: Sat, 14 Jun 2003 17:44:38 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1165
Importance: Normal
In-Reply-To: <p05210611bb11105f6e4f@[63.202.92.152]>
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Hoffman / IMC
> Sent: Saturday, June 14, 2003 10:51 AM
> To: [e-mail]
> Subject: Making AES a SHOULD in draft-ietf-smime-rfc2633bis?
> 
> Do we want to add AES as a SHOULD in section 2.7? We have the 
> traditional TripleDES MUST and RC2-40 as SHOULD. That's looking 
> backwards (some might say "very backwards" for RC2-40). It might be 
> good to add a forwards-looking SHOULD, namely AES.
> 
> How do others feel about this?

I wouldn't cry if we did this.  Does that help?

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5F0dWrb059602 for <[e-mail]>; Sat, 14 Jun 2003 17:39:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5F0dWet059601 for ietf-smime-bks; Sat, 14 Jun 2003 17:39:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5F0dVrb059595 for <[e-mail]>; Sat, 14 Jun 2003 17:39:31 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Sat, 14 Jun 2003 17:39:28 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Darrell Dykstra'" <[e-mail]>, <[e-mail]>
Subject: RE: Determining if a message has multiple layers without processing any of them
Date: Sat, 14 Jun 2003 17:39:28 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAf2obW/[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C3329B.E7B8BF30"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C3329B.E7B8BF30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In S/MIME, the layering is done using id-data elements for each
successive layer, since each layer is MIME encoded.  As soon as you
encounter an EnvelopedData, you basically have to stop unless you have
access to the plaintext contents.  In the mainstream case of signed,
then encrypted, I'm afraid that there isn't a way to determine the inner
S/MIME wrappings without the keying material for the EnvelopedData.  So
a pseudo-code algorithm for finding the types, given a top-level MIME
entity would probably be:
 
1. Determine the type of this entity by examining the Content-Type and
possibly the Content-Disposition and possibly the MIME decoded content
itself
 
2. If it's not a CMS type, then done
 
3. Add the CMS type to the list of types encountered
 
4. If the CMS type is id-envelopedData, and there is no keying material
to decrypt the data, then done
 
5. If there is no inner MIME data for this type (a certificates/CRLs
only SignedData, for instance), then done
 
6. Unwrap the inner MIME data, and set it to the current MIME entity
 
7. Go to step 1
 
There is not a way to parse the BER recursively to find the big picture
of the layers, so you're pretty much going to have to parse out the MIME
contents.
 
One observation -- the smime-type parameter is a hint to the top level
parser about what might be inside.  So it could very well be lying.  In
practice I have seen some instances of:
 
Content-Type: application/octet-stream
Content-Disposition: attachment;filename='smime.p7m'
 
(Sorry if the MIME is lousy, but you get the point).  In that case, you
have to bust open the top-level ContentInfo and extract the contentType
field to determine the CMS type of the data inside.
 
Blake

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Darrell Dykstra
Sent: Saturday, June 14, 2003 7:43 AM
To: '[e-mail]'
Subject: Determining if a message has multiple layers without processing
any of them



Hello, 

I am currently attempting to determine if there is anything in the
S/MIME standard that would allow me to determine if a message was, for
example, signed then encrypted, without processing any of the security
layers.

My understanding of the smime-type parameter is that it only applies to
the current layer of security, so for example, a message that was signed
and then encrypted will have an outer smime-type of enveloped-data with
no clue that there is a signature layer within.

Any insight into this is much appreciated. 

Thanks, 
Darrell 


------=_NextPart_000_003D_01C3329B.E7B8BF30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
S/MIME, the layering is done using id-data elements for each successive =
layer,=20
since each layer is MIME encoded.&nbsp; As soon as you encounter an=20
EnvelopedData, you basically have to stop unless you have access to the=20
plaintext contents.&nbsp; In the mainstream case of signed, then =
encrypted, I'm=20
afraid that there isn't a way to determine the inner S/MIME wrappings =
without=20
the keying material for the EnvelopedData.&nbsp; So a pseudo-code =
algorithm for=20
finding the types, given a top-level MIME&nbsp;entity would probably=20
be:</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>1.=20
Determine the type of this entity by examining the Content-Type and =
possibly the=20
Content-Disposition and possibly the MIME decoded content=20
itself</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>2. If=20
it's not a CMS type, then done</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>3. Add=20
the CMS type to the list of types encountered</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>4. If=20
the CMS type is id-envelopedData, and there is no keying material to =
decrypt the=20
data, then done</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>5. If=20
there is no inner MIME data for this type (a certificates/CRLs only =
SignedData,=20
for instance), then done</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>6.=20
Unwrap the inner MIME data, and set it to the current MIME=20
entity</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN><SPAN class=3D226141900-15062003><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>7. Go=20
to step 1</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>There=20
is not a way to parse the BER recursively to find the big picture of the =
layers,=20
so you're pretty much going to have to parse out the MIME=20
contents.</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>One=20
observation -- the smime-type parameter is a hint to the top level =
parser about=20
what might be inside.&nbsp; So it could very well be lying.&nbsp; In =
practice I=20
have seen some instances of:</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Content-Type: application/octet-stream</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Content-Disposition: =
attachment;filename=3D'smime.p7m'</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =
size=3D2>(Sorry=20
if the MIME is lousy, but you get the point).&nbsp; In that case, you =
have to=20
bust open the top-level ContentInfo and extract the contentType field to =

determine the CMS type of the data inside.</FONT></SPAN></DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D226141900-15062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Blake</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Darrell Dykstra<BR><B>Sent:</B> Saturday, June 14, 2003 =
7:43=20
  AM<BR><B>To:</B> '[e-mail]'<BR><B>Subject:</B> Determining =
if a=20
  message has multiple layers without processing any of=20
them<BR><BR></FONT></DIV>
  <P><FONT face=3DArial size=3D2>Hello,</FONT> </P>
  <P><FONT face=3DArial size=3D2>I am currently attempting to determine =
if there is=20
  anything in the S/MIME standard that would allow me to determine if a =
message=20
  was, for example, signed then encrypted, without processing any of the =

  security layers.</FONT></P>
  <P><FONT face=3DArial size=3D2>My understanding of the smime-type =
parameter is=20
  that it only applies to the current layer of security, so for example, =
a=20
  message that was signed and then encrypted will have an outer =
smime-type of=20
  enveloped-data with no clue that there is a signature layer =
within.</FONT></P>
  <P><FONT face=3DArial size=3D2>Any insight into this is much =
appreciated.</FONT>=20
  </P>
  <P><FONT face=3DArial size=3D2>Thanks,</FONT> <BR><FONT face=3DArial=20
  size=3D2>Darrell</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003D_01C3329B.E7B8BF30--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5EHpPrb047971 for <[e-mail]>; Sat, 14 Jun 2003 10:51:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5EHpPnC047970 for ietf-smime-bks; Sat, 14 Jun 2003 10:51:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5EHpLrg047948 for <[e-mail]>; Sat, 14 Jun 2003 10:51:24 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210611bb11105f6e4f@[63.202.92.152]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sat, 14 Jun 2003 10:51:18 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Making AES a SHOULD in draft-ietf-smime-rfc2633bis?
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>

Greetings again. draft-ietf-smime-rfc2633bis is in WG last call, and 
I should have probably brought this up before, but...

Do we want to add AES as a SHOULD in section 2.7? We have the 
traditional TripleDES MUST and RC2-40 as SHOULD. That's looking 
backwards (some might say "very backwards" for RC2-40). It might be 
good to add a forwards-looking SHOULD, namely AES.

How do others feel about this?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5EEhXrb039886 for <[e-mail]>; Sat, 14 Jun 2003 07:43:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5EEhXjj039885 for ietf-smime-bks; Sat, 14 Jun 2003 07:43:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5EEhWrb039879 for <[e-mail]>; Sat, 14 Jun 2003 07:43:32 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V5EE248X15864 for <[e-mail]>; Sat, 14 Jun 2003 10:40:08 -0400
Received: (qmail 8474 invoked by uid 64014); 14 Jun 2003 14:39:19 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.23272 secs); 14 Jun 2003 14:39:19 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 14 Jun 2003 14:39:19 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <MX4A8XH9>; Sat, 14 Jun 2003 10:43:27 -0400
Message-ID: <[e-mail]>
From: Darrell Dykstra <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Determining if a message has multiple layers without processing a ny of them
Date: Sat, 14 Jun 2003 10:43:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33283.506AD8B0"
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_001_01C33283.506AD8B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

I am currently attempting to determine if there is anything in the S/MIME
standard that would allow me to determine if a message was, for example,
signed then encrypted, without processing any of the security layers.

My understanding of the smime-type parameter is that it only applies to the
current layer of security, so for example, a message that was signed and
then encrypted will have an outer smime-type of enveloped-data with no clue
that there is a signature layer within.

Any insight into this is much appreciated.

Thanks,
Darrell

------_=_NextPart_001_01C33283.506AD8B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Determining if a message has multiple layers without processing =
any of them</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am currently attempting to determine =
if there is anything in the S/MIME standard that would allow me to =
determine if a message was, for example, signed then encrypted, without =
processing any of the security layers.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">My understanding of the smime-type =
parameter is that it only applies to the current layer of security, so =
for example, a message that was signed and then encrypted will have an =
outer smime-type of enveloped-data with no clue that there is a =
signature layer within.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Any insight into this is much =
appreciated.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Darrell</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C33283.506AD8B0--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CBBjrb048798 for <[e-mail]>; Thu, 12 Jun 2003 04:11:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CBBjWD048797 for ietf-smime-bks; Thu, 12 Jun 2003 04:11:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CBBirb048788 for <[e-mail]>; Thu, 12 Jun 2003 04:11:44 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Thu, 12 Jun 2003 04:11:39 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Alberti Antoine'" <[e-mail]>, <[e-mail]>
Subject: RE: RFC-draft evolutions
Date: Thu, 12 Jun 2003 04:11:39 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAVLv7Qye3OEarfITWS/[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.2800.1165
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alberti Antoine
> Sent: Thursday, June 12, 2003 3:13 AM
> To: '[e-mail]'
> Subject: RFC-draft evolutions
> 
> Moreover, I am surprised to see that, in the document
> draft-ietf-smime-rfc2632bis-03.txt, there is not a list of 
> changes since RFC
> 2632, like in draft-ietf-smime-rfc2633bis-04.txt.

This was a mistake on my part, and I will be including this in the next
revision.  I mentioned that this was work to be done at the last WG
meeting and then forgot to include it.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CACvrb044907 for <[e-mail]>; Thu, 12 Jun 2003 03:12:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CACvNG044906 for ietf-smime-bks; Thu, 12 Jun 2003 03:12:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sopragroup.com (smtp1.zpar1.sopragroup.com [213.223.36.98]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5CACtrb044900 for <[e-mail]>; Thu, 12 Jun 2003 03:12:56 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 7711 invoked from network); 12 Jun 2003 10:12:48 -0000
Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 12 Jun 2003 10:12:48 -0000
Received: by nt1022.pa.sopra with Internet Mail Service (5.5.2653.19) id <MWZPJ46C>; Thu, 12 Jun 2003 12:12:47 +0200
Message-ID: <[e-mail]>
From: Alberti Antoine <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RFC-draft evolutions
Date: Thu, 12 Jun 2003 12:12:46 +0200
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 was wondering where I could find lists of evolutions between the different
versions of a draft. Do I really have to save the different versions of a
document and perform diffs on them to know if the differences are
interesting to me?
Moreover, I am surprised to see that, in the document
draft-ietf-smime-rfc2632bis-03.txt, there is not a list of changes since RFC
2632, like in draft-ietf-smime-rfc2633bis-04.txt. It seems to me that this
would particularly be interesting for such standards, where many paragraphs
are exactly the same from one version to another. More generally, why is
this history not systematic?
Thanks in advance.

> 	
> 
> 	Antoine Alberti			Axway.  a Sopra Group company	
> 	email: [e-mail]
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57MNiAF031153 for <[e-mail]>; Sat, 7 Jun 2003 15:23:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h57MNiuL031152 for ietf-smime-bks; Sat, 7 Jun 2003 15:23:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57MNhAF031147 for <[e-mail]>; Sat, 7 Jun 2003 15:23:43 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 3650070FB5 for <[e-mail]>; Sat,  7 Jun 2003 15:23:45 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: MLA Processing Questions
Date: Sat, 7 Jun 2003 15:23:36 -0700
Message-ID: <003e01c32d43$70732940$[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.2800.1165
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>

A couple of additional questions for consideration.

1.  Consider the message S1(S2(S3(M))) where S2 has an
MLExpansionHistory attribute and S1 has a ESSSecurityLabel attribute.
Under the current processing rules the security label would not be on
the output message of an MLA.  Attributes on S2 are preserved, but not
those on S1.  Does this need to be changed?

2.  Are there any other attributes for which this needs to be changed as
well?

3.  If you have the message S1(S2(E1(S3(M)))), if S1 or S2 contains an
ESSSecurityLabel attribute it would be preserved only if there was an
MLExpansionHistory attribute in the same signature layer.

4.  Are there any other attributes that need to be preserved here as
well.

5.  There is a rule that states all attributes need to be kept unless
replaced.  This needs to be modified to exclude the
id-aa-SigningCertificate attribute.  If this element is not replaced but
copied then the signature of the MLA SHOULD fail validation.  Can
anybody else think of attributes for which this is also true.

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57LTYAF029993 for <[e-mail]>; Sat, 7 Jun 2003 14:29:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h57LTYsH029992 for ietf-smime-bks; Sat, 7 Jun 2003 14:29:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57LTXAF029987 for <[e-mail]>; Sat, 7 Jun 2003 14:29:33 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 226456A46B for <[e-mail]>; Sat,  7 Jun 2003 14:29:24 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: MLA Expansion History processing questions
Date: Sat, 7 Jun 2003 14:29:14 -0700
Message-ID: <003d01c32d3b$d8aea370$[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.2800.1165
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>

Consider the following message  S1(S2(M)).  

1. S1 contains a two different SignerInfos.  SignerInfo #1 cannot be
validated and contains an MLA Expansion history element.  SignerInfo #2
can be validated.  Does the MLA stop processing of the message?  This is
the case if there were two different MLA Expansion history elements, but
this case is not explicity addressed.

2.  S1 validates and contains an MLA Expansion history element.  S2
fails validation.  Since the MLA could in theory just evaluate S1 and
not look at S2, is it considered to be illeagle behavior (i.e. MUST stop
processing) to pass on this message?

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57KvZAF029291 for <[e-mail]>; Sat, 7 Jun 2003 13:57:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h57KvZTL029290 for ietf-smime-bks; Sat, 7 Jun 2003 13:57:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57KvYAF029284 for <[e-mail]>; Sat, 7 Jun 2003 13:57:34 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id D60746DB03 for <[e-mail]>; Sat,  7 Jun 2003 13:57:35 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: Receipt Processing Behavior
Date: Sat, 7 Jun 2003 13:57:26 -0700
Message-ID: <003c01c32d37$672e61d0$[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.2800.1165
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>

What is the correct behavior for the following?   I can see different
arguments.

Consider the following S1(S2(S3(M))) where

S3 contains a receipt request
S2 contains an MLExpansionHistory (now a ReceiptPolicy attribute) which
says NONE
S3 contains a ReceiptPolicy attribute which says - add
[e-mail]

Should the receipt be created or not?

jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57JoQAF023401 for <[e-mail]>; Sat, 7 Jun 2003 12:50:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h57JoQX2023400 for ietf-smime-bks; Sat, 7 Jun 2003 12:50:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57JoPAF023395 for <[e-mail]>; Sat, 7 Jun 2003 12:50:25 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id D474F6A83B for <[e-mail]>; Sat,  7 Jun 2003 12:29:17 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: Receipt Request Processing Questions
Date: Sat, 7 Jun 2003 12:49:59 -0700
Message-ID: <003901c32d2d$fb071730$[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.2800.1165
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>

The following do not appear to be well address in the present ESS
document.  

1.  For the message S1(S2(M)) - If S2 validates and contains a receipt
request but S1 fails to validate.  Should the receipt be generated?

2.  For the message S1(S2(M)) - If S2 validates and contains a receipt
request, S1 contains an MLExpansionHistory attribute, but cannot be
validate due to either a) missing certificate or b) unknown signing
algorithm.  Should a) the receipt be generated and b) the
MLExpansionHistory attribute be obeyed?

3.  The following is a "new" case  S1(E1(?)) - S1 contains a receipt
request, E1 cannot be decrypted due to the lack of a lock box for the
receipient.  Should a receipt be generated?

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h572wYAF044816 for <[e-mail]>; Fri, 6 Jun 2003 19:58:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h572wYcq044815 for ietf-smime-bks; Fri, 6 Jun 2003 19:58:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h572wWAF044807 for <[e-mail]>; Fri, 6 Jun 2003 19:58:33 -0700 (PDT) (envelope-from [e-mail])
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h572wSjc028705; Fri, 6 Jun 2003 19:58:28 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHW76812; Fri, 6 Jun 2003 19:54:14 -0700 (PDT)
Date: Fri, 6 Jun 2003 19:59:22 -0700
Subject: proposed addition to application/pkcs7-mime smime parameter
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: [e-mail], [e-mail]
To: Blake Ramsdell <[e-mail]>
From: Rohan Mahy <[e-mail]>
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.552)
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>

Hello,

At IETF 56, I presented about SIP's use of S/MIME and CMS. One of the 
suggestions that I received from the group was that SIP should use raw 
CMS instead of S/MIME.  In order to convey CMS types not used by S/MIME 
(especially AuthenticatedData), it would be very convenient to have a 
MIME type registration for CMS which incorporated these types.

When draft-ietf-smime-2633bis progresses, it will hold the MIME type 
registration for application/pkcs7-mime.  Today, we could represent 
authenticated data by using the smime-type parameter with the complete 
oid for authentcated data but that is very cumbersome.  It would be 
very convenient for future uses of CMS if the types were already 
defined with the application/pkcs7-mime MIME type.

I have included some proposed text to add the other CMS types to the 
smime-type mime parameter.  Alternatively a new cms-type mime parameter 
could be defined, but this seems a but pedantic to me.

thanks,
-rohan


from 2633bis:
> 3.2.2 The smime-type parameter
>
> The application/pkcs7-mime content type defines the optional "smime-
> type" parameter. The intent of this parameter is to convey details
> about the security applied (signed or enveloped) along with infomation
> about the contained content. This specification defines the following
> smime-types.
>
> Name                   CMS type                Inner Content
>
> enveloped-data         EnvelopedData           id-data
>
> signed-data            SignedData              id-data
>
> certs-only             SignedData              none
>
> compressed-data        CompressedData          id-data


Proposed replacement text follows:

3.2.2 The smime-type parameter

The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with infomation
about the contained content. This specification defines the following
smime-types. (For completeness all CMS types are defined, even
those not used by S/MIME)

Name                   CMS type                Inner Content

enveloped-data         EnvelopedData           id-data

signed-data            SignedData              id-data

certs-only             SignedData              none

compressed-data        CompressedData          id-data

authenticated-data     AuthenticatedData  *    id-data

digested-data          DigestedData       *    id-data

encrypted-data         EncryptedData      *    id-data

*Note that these CMS types are not used by S/MIME




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56BUhAF007621 for <[e-mail]>; Fri, 6 Jun 2003 04:30:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56BUhkP007620 for ietf-smime-bks; Fri, 6 Jun 2003 04:30:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56BUfAF007613 for <[e-mail]>; Fri, 6 Jun 2003 04:30:42 -0700 (PDT) (envelope-from [e-mail])
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2395E812E for <[e-mail]>; Fri,  6 Jun 2003 07:30:42 -0400 (EDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 2A8C110AB for <[e-mail]>; Fri,  6 Jun 2003 07:30:37 -0400 (EDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <L7G4ZA3W>; Fri, 6 Jun 2003 17:03:25 +0530
Message-ID: <[e-mail]>
From: "Pandey, Arun" <[e-mail]>
To: [e-mail]
Subject: Loss of Information while mapping an Internet S/MIME Message to X .400.
Date: Fri, 6 Jun 2003 17:03:25 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C1F.71328350"
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_001_01C32C1F.71328350
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

As per draft-ietf-smime-x400transport-07.txt:
"When transporting a CMS-protected message in X.400, the preferred approach
is to
convey the object as X.400 message content. Implementations MUST include the
CMS 
object in the content field of the X.400 message."

However when mapping an Internet S/MIME message to an X.400 Message:
1. The CMS object is placed in the X.400 Message Content (as recommended).
2. The RFC 822 header fields of the Internet message that can be mapped
directly 
   to the X.400 envelope fields are placed in the X.400 Message Envelope.

3. This leaves out the Internet Message header fields that are normally
mapped to 
   the IPM Content Heading fields. In the X.400 Content carrying the CMS
object 
   there are no corresponding fields for them. As a result such fields
apparently 
   cannot be mapped to the X.400 message and will be lost (on conversion
from 
   Internet to X.400 message). Such fields are :
   Subject, From, To, Reply-to, In-reply-to, Message-id, cc, bcc, Sender,
Expiry-
   date, Deferred-delivery-date, Latest-delivery-time, Importance,
Sensitivity, 
   Language and References.
   
How can this loss of information be avoided, what is the recommended way
around 
this particular problem?

The possible workarounds could be:

1. The Internet User Agent constructing an S/MIME message SHOULD place the 
   message content along with these fields into a Message/rfc-822 content
before 
   securing it. This should be done if these fields are desired to be seen
by 
   the receiving user agent (in case the message is to be transported over
an 
   X.400 network.)

   But I found that existing applications like Microsoft Outlook do not
provide 
   an option to perform an Message/rfc-822 wrapping of these fileds.

2. Another solution could be to map the CMS object in an IPMS content,
wherein
   the above fields could then be mapped to the IPMS content heading fields,
and 
   the CMS object could be placed in an appropriate bodypart (ftbp with file
type 
   as smime.p7m). 
   
   But this goes against the recommendation "Implementations generally
SHOULD 
   NOT embed CMS objects within X.400 body parts, but should instead convey
them 
   as content as described in sec. 2.2" of
draft-ietf-smime-x400transport07.txt.

Best Regards
Arun Pandey

------_=_NextPart_001_01C32C1F.71328350
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>Loss of Information while mapping an Internet S/MIME Message to X.400.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi,</FONT>
</P>

<P><FONT SIZE=2>As per draft-ietf-smime-x400transport-07.txt:</FONT>
<BR><FONT SIZE=2>&quot;When transporting a CMS-protected message in X.400, the preferred approach is to</FONT>
<BR><FONT SIZE=2>convey the object as X.400 message content. Implementations MUST include the CMS </FONT>
<BR><FONT SIZE=2>object in the content field of the X.400 message.&quot;</FONT>
</P>

<P><FONT SIZE=2>However when mapping an Internet S/MIME message to an X.400 Message:</FONT>
<BR><FONT SIZE=2>1. The CMS object is placed in the X.400 Message Content (as recommended).</FONT>
<BR><FONT SIZE=2>2. The RFC 822 header fields of the Internet message that can be mapped directly </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; to the X.400 envelope fields are placed in the X.400 Message Envelope.</FONT>
</P>

<P><FONT SIZE=2>3. This leaves out the Internet Message header fields that are normally mapped to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the IPM Content Heading fields. In the X.400 Content carrying the CMS object </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; there are no corresponding fields for them. As a result such fields apparently </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; cannot be mapped to the X.400 message and will be lost (on conversion from </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Internet to X.400 message). Such fields are :</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Subject, From, To, Reply-to, In-reply-to, Message-id, cc, bcc, Sender, Expiry-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; date, Deferred-delivery-date, Latest-delivery-time, Importance, Sensitivity, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Language and References.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>How can this loss of information be avoided, what is the recommended way around </FONT>
<BR><FONT SIZE=2>this particular problem?</FONT>
</P>

<P><FONT SIZE=2>The possible workarounds could be:</FONT>
</P>

<P><FONT SIZE=2>1. The Internet User Agent constructing an S/MIME message SHOULD place the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; message content along with these fields into a Message/rfc-822 content before </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; securing it. This should be done if these fields are desired to be seen by </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the receiving user agent (in case the message is to be transported over an </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; X.400 network.)</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; But I found that existing applications like Microsoft Outlook do not provide </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; an option to perform an Message/rfc-822 wrapping of these fileds.</FONT>
</P>

<P><FONT SIZE=2>2. Another solution could be to map the CMS object in an IPMS content, wherein</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the above fields could then be mapped to the IPMS content heading fields, and </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; the CMS object could be placed in an appropriate bodypart (ftbp with file type </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; as smime.p7m). </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; But this goes against the recommendation &quot;Implementations generally SHOULD </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; NOT embed CMS objects within X.400 body parts, but should instead convey them </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; as content as described in sec. 2.2&quot; of draft-ietf-smime-x400transport07.txt.</FONT>
</P>

<P><FONT SIZE=2>Best Regards</FONT>
<BR><FONT SIZE=2>Arun Pandey</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C32C1F.71328350--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54KOfAF055162 for <[e-mail]>; Wed, 4 Jun 2003 13:27:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54KOf7R055161 for ietf-smime-bks; Wed, 4 Jun 2003 13:24:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54KMAAF055120 for <[e-mail]>; Wed, 4 Jun 2003 13:24:40 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 4 Jun 2003 13:22:07 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: WG LAST CALL: draft-ietf-smime-rfc2632bis-03
Date: Wed, 4 Jun 2003 13:22:07 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAArOG3H4vmqkCKD2y8D/[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.2800.1106
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>

This message initiates an SMIME Working Group Last Call on the document:

	Title		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-03.txt
	Pages		: 0
	Date		: 2003-2-20

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

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues may
be sent to the document editor.

The Last Call period will end on Wednesday, June 18, 2003.

Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:

   1) recommending to the IETF Security Area Directors
      that the document, after possible editorial or
      other minor changes, be considered by the IESG
      for publication as a Standard Track RFC
      (which generally involves an IETF-wide Last Call); or

   2) requiring that outstanding issues be adequately
      addressed prior to further action (including,
      possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

This boilerplate was provided courtesy of the SASL working group.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54KJDAF054994 for <[e-mail]>; Wed, 4 Jun 2003 13:21:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54KJDn1054993 for ietf-smime-bks; Wed, 4 Jun 2003 13:19:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54KGfAF054960 for <[e-mail]>; Wed, 4 Jun 2003 13:19:12 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 4 Jun 2003 13:16:39 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Date: Wed, 4 Jun 2003 13:16:38 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1106
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>

This message initiates an SMIME Working Group Last Call on the document:

	Title		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-04.txt
	Pages		: 0
	Date		: 2003-6-3

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

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues may
be sent to the document editor.

The Last Call period will end on Wednesday, June 18, 2003.

Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:

   1) recommending to the IETF Security Area Directors
      that the document, after possible editorial or
      other minor changes, be considered by the IESG
      for publication as a Standard Track RFC
      (which generally involves an IETF-wide Last Call); or

   2) requiring that outstanding issues be adequately
      addressed prior to further action (including,
      possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

This boilerplate was provided courtesy of the SASL working group.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54DltAF031850 for <[e-mail]>; Wed, 4 Jun 2003 06:47:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54DltSC031849 for ietf-smime-bks; Wed, 4 Jun 2003 06:47:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54DlsAF031844 for <[e-mail]>; Wed, 4 Jun 2003 06:47:55 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19311; Wed, 4 Jun 2003 09:47:53 -0400 (EDT)
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-rfc2633bis-04.txt
Date: Wed, 04 Jun 2003 09:47:53 -0400
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		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-04.txt
	Pages		: 0
	Date		: 2003-6-3
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and data confidentiality (using encryption).

S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.

Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54BxfAF028272 for <[e-mail]>; Wed, 4 Jun 2003 05:02:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54Bxfol028271 for ietf-smime-bks; Wed, 4 Jun 2003 04:59:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54BwGAF028221 for <[e-mail]>; Wed, 4 Jun 2003 04:59:41 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13094; Wed, 4 Jun 2003 07:58:16 -0400 (EDT)
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-rfc2633bis-04.txt
Date: Wed, 04 Jun 2003 07:58:15 -0400
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		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-04.txt
	Pages		: 0
	Date		: 2003-6-3
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and data confidentiality (using encryption).

S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.

Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54944AF014534 for <[e-mail]>; Wed, 4 Jun 2003 02:06:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54943wJ014533 for ietf-smime-bks; Wed, 4 Jun 2003 02:04:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5491WAF014396 for <[e-mail]>; Wed, 4 Jun 2003 02:04:03 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 4 Jun 2003 02:01:27 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: example 5.2 basic signed content RSA
Date: Wed, 4 Jun 2003 02:01:27 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[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.2800.1106
Importance: Normal
In-Reply-To: <000901c32a66$61ab1a60$[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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ronen
> Sent: Tuesday, June 03, 2003 11:56 PM
> To: [e-mail]
> Subject: example 5.2 basic signed content RSA
> 
> -------------- The start of the Certificate -------------------
> 
>   84 A0  560:       [0] {
>   88 30  556:         SEQUENCE {       <------ why not SET !!! ? ? ? ?
>   92 30  405:           SEQUENCE {
>   96 A0    3:             [0] {
>   98 02    1:               INTEGER 2
>             :               }
> 101 02   16:             INTEGER
>             :               46 34 6B C7 80 00 56 BC 11 D3 6E 2E
>             :               C4 10 B3 B0

I believe you're out of sync.  Annotated, I believe this example
corresponds to the following:

>   84 A0  560:       [0] { -- CertificateSet
>   88 30  556:         SEQUENCE { -- Certificate
>   92 30  405:           SEQUENCE { -- TBSCertificate
>   96 A0    3:             [0] { -- Version
>   98 02    1:               INTEGER 2
>             :               }
> 101 02   16:             INTEGER
>             :               46 34 6B C7 80 00 56 BC 11 D3 6E 2E
>             :               C4 10 B3 B0

I think the SET for CertificateSet is implicit, and is replaced by the
[0] tag.  The SEQUENCE you point out belongs to the first Certificate in
the set.  I could be lying, however.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54731AF095995 for <[e-mail]>; Wed, 4 Jun 2003 00:05:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54731Ai095994 for ietf-smime-bks; Wed, 4 Jun 2003 00:03:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.discretix.com (bzq-219-176-82.dsl.bezeqint.net [62.219.176.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5470SAF095553 for <[e-mail]>; Wed, 4 Jun 2003 00:02:59 -0700 (PDT) (envelope-from [e-mail])
Received: from ronengdesk (fwdiscretix [62.219.176.93]) by mail.discretix.com (8.12.2/8.12.2) with SMTP id h5475Cam027421 for <[e-mail]>; Wed, 4 Jun 2003 10:05:12 +0300 (IDT)
Reply-To: <[e-mail]>
From: "Ronen" <[e-mail]>
To: <[e-mail]>
Subject: example 5.2 basic signed content RSA
Date: Wed, 4 Jun 2003 09:56:09 +0300
Message-ID: <000901c32a66$61ab1a60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

hi,
i am coding CMS ( RFC3380 ) and i was parsing example 5.2 at
draft-ietf-smime-examples-10.txt and got to the Certificate part.
i like to know why it is SEQUENCE ( in the example ) and not SET OF  (as
like in the CMS RFC3380 ).

This is how it is defined in the RFC :
SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

 CertificateSet ::= SET OF CertificateChoices


in draft-ietf-smime-examples-10.txt  ex5.2 Basic signed content it is :
-------------------- Content Info -----------------------
-
 0 30  850: SEQUENCE {

-------------------- Content Type -----------------------

   4 06    9:   OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
            :     (PKCS #7)

------ content [0] EXPLICIT ANY DEFINED BY contentType ---------

  15 A0  835:   [0] {

--------------------- SignedData -------------------------------
----
  19 30  831:     SEQUENCE {

--------------------  version ----------------------------------
  23 02    1:       INTEGER 1
-------------------- digestAlgorithems -------------------------
  26 31   11:       SET {
  28 30    9:         SEQUENCE {
  30 06    5:           OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            :             (OIW)
  37 05    0:           NULL
            :           }
----------------------------------------------------------------
            :         }
-------------------------- encapsulated Content ----------------
  39 30   43:       SEQUENCE {
  41 06    9:         OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
            :           (PKCS #7)
  52 A0   30:         [0] {
  54 04   28:           OCTET STRING 'This is some sample content.'
            :           }
            :         }

-------------- The start of the Certificate -------------------

  84 A0  560:       [0] {
  88 30  556:         SEQUENCE {       <------ why not SET !!! ? ? ? ?
  92 30  405:           SEQUENCE {
  96 A0    3:             [0] {
  98 02    1:               INTEGER 2
            :               }
101 02   16:             INTEGER
            :               46 34 6B C7 80 00 56 BC 11 D3 6E 2E
            :               C4 10 B3 B0
119 30   13:             SEQUENCE {
121 06    9:               OBJECT IDENTIFIER
            :                 sha1withRSAEncryption
            :                     (1 2 840 113549 1 1 5)
            :                 (PKCS #1)
132 05    0:               NULL
            :               }
134 30   18:             SEQUENCE {
136 31   16:               SET {
138 30   14:                 SEQUENCE {
140 06    3:                   OBJECT IDENTIFIER


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52JN9AF064872 for <[e-mail]>; Mon, 2 Jun 2003 12:23:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h52JN9cn064871 for ietf-smime-bks; Mon, 2 Jun 2003 12:23:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52JN8AF064851 for <[e-mail]>; Mon, 2 Jun 2003 12:23:08 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Mon, 2 Jun 2003 12:22:58 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Jacoby, Jeffrey'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-aes-alg-07.txt
Date: Mon, 2 Jun 2003 12:22:57 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAW7GZsWFGgUmi/[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.2800.1106
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jacoby, Jeffrey
> Sent: Monday, June 02, 2003 7:30 AM
> To: '[e-mail]'
> Subject: Re: I-D ACTION:draft-ietf-smime-aes-alg-07.txt
> 
> 2. In section 1 Overview, the Distinguished Encoding Rules 
>    reference (DER) is given as X.509-88.  Was X.209-88 meant instead?

My understanding is that if you refer to "old school" DER (that is, a
pre-X.690 reference), you need to refer to the X.509 specification (DER
was not defined in X.209, only BER).

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52F9LAF045853 for <[e-mail]>; Mon, 2 Jun 2003 08:09:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h52F9LAZ045852 for ietf-smime-bks; Mon, 2 Jun 2003 08:09:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52F9KAF045847 for <[e-mail]>; Mon, 2 Jun 2003 08:09:20 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11062; Mon, 2 Jun 2003 11:09:18 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Use of the AES Encryption Algorithm in CMS  to Proposed Standard
Date: Mon, 02 Jun 2003 11:09:17 -0400
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 IESG has approved the Internet-Draft 'Use of the AES Encryption 
 Algorithm in CMS' <draft-ietf-smime-aes-alg-07.txt> as a Proposed 
 Standard. This document is the product of the S/MIME Mail Security 
 Working Group. The IESG contact persons are Steven Bellovin and
 Russ Housley.
   
   
 Technical Summary
   
   This specification describes how to use the Advanced Encryption
   Standard (AES) with the Cryptographic Message Syntax (CMS).
   It gives the ASN.1 necessary when AES is used with each
   recipient's public RSA key, with a Diffie-Hellman key exchange,
   with a previously distributed symmetric key, and with a
   key derived from a password.
   
 Working Group Summary
   
   There was no significant disagreement.
   
 Protocol Quality
   
   This specification was reviewed for the IESG by Steve Bellovin.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52EUcAF044080 for <[e-mail]>; Mon, 2 Jun 2003 07:30:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h52EUcGx044079 for ietf-smime-bks; Mon, 2 Jun 2003 07:30:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.12.9/8.12.8) with SMTP id h52EUWAF044059 for <[e-mail]>; Mon, 2 Jun 2003 07:30:33 -0700 (PDT) (envelope-from [e-mail])
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Jun 2003 14:30:34 UT
Received: from exrsa01.rsa.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (8.11.6p2/8.11.6) with ESMTP id h52EUUc13805 for <[e-mail]>; Mon, 2 Jun 2003 10:30:30 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <L5XNQ7Z9>; Mon, 2 Jun 2003 07:30:29 -0700
Message-ID: <[e-mail]>
From: "Jacoby, Jeffrey" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-aes-alg-07.txt
Date: Mon, 2 Jun 2003 07:30:21 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

A few minor editorial comments:


1. I'm seeing way too many blank lines in the middle of
   paragraphs (maybe it's just my browser).


2. In section 1 Overview, the Distinguished Encoding Rules 
   reference (DER) is given as X.509-88.  Was X.209-88 meant instead?


3. Maybe this is just a stylistic nit in my part, but the
   first paragraph or two of section 2.2 is just a repeat
   of [CMS].  Would a statement like:

     "See [CMS] section 6.2.1 for details of selecting
      the proper KeyTransRecipientInfo version value."

   be sufficient?  


4. In section 2.2  KeyTransRecipientInfo Fields, the next to
   last paragraph reads:

     "The KeyTransRecipientInfo keyEncryptionAlgorithm field 
      specifies the key transport algorithm (i.e. RSAES-OAEP [RSA-OAEP]), 
      and the associated parameters used to encrypt the CEK for 
      the recipient."

   In the parenthetical comment, use of "i.e." implies--to me at least--
   that RSAES-OAEP is the only key transport algorithm.  I think "e.g." 
   would better indicate RSAES-OAEP is one of several algorthims
   that might be used (RSAES-OAEP, PKCS#1v1.5).  


5. In section 4.1  Algorithm Identifiers and Parameters,
   it would be nice to see an initial definition of the
   "aes" identifier:

      aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 
                                  us(840) organization(1) gov(101) 
                                  csor(3) nistAlgorithms(4)  1 } 

   *before* it gets referenced in other OID definitions.  I know 
   it's given in Appendix A, but it couldn't hurt to see it in the 
   text of section 4.1 as well.  

   Related to this, the definition in the appendix has a spurious 
   trailing underscore after the "csor(3)" part:

      aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 
                   organization(1) gov(101) csor(3)_ nistAlgorithms(4)  1 } 


That's all (for now),


Jeff


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h51IrhAF040690 for <[e-mail]>; Sun, 1 Jun 2003 11:53:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h51IrhTU040688 for ietf-smime-bks; Sun, 1 Jun 2003 11:53:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h51IrfAF040670; Sun, 1 Jun 2003 11:53:41 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 90FAC6AAFA; Sun,  1 Jun 2003 11:33:04 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Post-last-call status of the S/MIME examples draft
Date: Sun, 1 Jun 2003 11:53:37 -0700
Message-ID: <005501c3286f$1ed3be20$[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
In-Reply-To: <001601c323fa$d85cc360$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

8.1.bin
	Jim Schaad:  Pass

8.2.bin
	Jim Schaad:  BIG FAIL
		1) The key is not in the text.  Assuming it's the same
as 8.1 does not work
		2) The encapsulated content type is EncryptedData not
id-data
		3) The content hint content type does not match the
encapsulated content type.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Jim Schaad
> Sent: Monday, May 26, 2003 7:51 PM
> To: 'Paul Hoffman / IMC'; [e-mail]; 
> [e-mail]
> Subject: RE: Post-last-call status of the S/MIME examples draft
> 
> 
> 
> Some more input
> 
> 5.9.eml
> 	Jim Schaad:  Fail
> 		signatureAlgorithm of dsa not dsaWithSha1
> 
> 11.3.bin
> 	Jim Schaad:  Pass
> 
> I think I should be able to work through all of sections 6, 8 
> & 9 by the end of this week.  I don't have anything external 
> on my plate at the moment.
> 
> jim
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Paul 
> Hoffman / IMC
> > Sent: Friday, May 23, 2003 6:11 AM
> > To: [e-mail]; [e-mail]
> > Subject: Post-last-call status of the S/MIME examples draft
> > 
> > 
> > 
> > Greetings again. Here's my collected notes from the WG mailing list,
> > the smime-examples mailing list, and off-list mail. I summarize at 
> > the end.
> > 
> > ====================
> > 
> > 4. Trivial Examples
> > 
> > 4.1 ContentInfo with Data type, BER
> >    John Pawling: tested OK.
> >    Jim Schaad: tested OK.
> > 
> > 4.2 ContentInfo with Data type, DER
> >    John Pawling: tested OK.
> >    Jim Schaad: tested OK.
> > 
> > 5.  Signed-data
> >    Jim Schaad pointed out that many examples had the
> >      signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it
> > should instead
> >      be 1.2.840.10040.4.3 (dsaWithSha1).
> >    The general decision was that the examples should have 
> dsaWithSha1.
> >    John Pawling and Sue Beauchamp at DigitalNet agreed to 
> re-generate
> >      the examples.
> > 
> > 5.1 Basic signed content, DSS
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: failed.
> >      signatureAlgorithm is dsa but should be dsaWithSha1
> >    Sue Beauchamp sent new example file.
> > 
> > 5.2 Basic signed content, RSA
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: tested OK.
> > 
> > 5.3 Basic signed content, detached content
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: failed.
> > 	Contains Alice's RSA certificate
> > 	No content hint unsigned attribute
> >      signatureAlgorithm is dsa but should be dsaWithSha1
> >    Sue Beauchamp sent new example file.
> > 
> > 5.4 Fancier signed content
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Sue Beauchamp sent new example file.
> > 
> > 5.5 All RSA signed message
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: tested OK.
> > 
> > 5.6 Multiple signers
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: failed.
> >      signatureAlgorithm is dsa but should be dsaWithSha1
> >    Sue Beauchamp sent new example file.
> > 
> > 5.7 Signing using SKI
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: failed.
> >      signatureAlgorithm is dsa but should be dsaWithSha1
> >    Sue Beauchamp sent new example file.
> > 
> > 5.8 S/MIME multipart/signed message
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> > 
> > 5.9 S/MIME application/pkcs7-mime signed message
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> > 
> > 5.10 SignedData With Attributes
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> >    Jim Schaad: failed.
> > 	Change "unknown OID" to "unknown OID (1.2.5555)"
> > 	Content Hint should have an OID of 1.2.840.113549.1.7.1
> > 	Content Identifier attribute absent
> > 	Contains Security Label attribute
> > 	Contains encrypt key preference attribute
> > 	Contains ML Expansion History attribute
> > 	Contains Equivalent Label attribute
> > 
> > 5.11 SignedData with Certificates Only
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> > 
> > 6.  Enveloped-data
> > 
> > 6.1 Basic encrypted content, TripleDES and DH
> >    John Pawling: tested OK.
> > 
> > 6.2 Basic encrypted content, TripleDES and RSA
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> > 
> > 6.3 Basic encrypted content, RC2/40 and RSA
> >    Blake Ramsdell: this is actually a 128-bit key.
> >    Jeff Jacoby: confirmed Blake's assertion.
> >    Paul Hoffman: thinks we could just change the title of 
> the example.
> >    John Pawling: tested OK.
> >    Blake Ramsdell: tested OK.
> > 
> > 6.4 Encrypted content, two recipients, no shared keying material
> >    John Pawling: tested OK but noted unsuccessful Invalid tag for
> >      privateKeyInfo for second login.
> > 
> > 6.5 Encrypted content, two recipients, shared keying material
> >    John Pawling: could not test due to bug in his code.
> > 
> > 6.6 Encrypted content, TripleDES and DH, previously-distributed keys
> >    John Pawling: tested OK.
> > 
> > 6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys
> >    John Pawling: tested OK.
> > 
> > 6.8 S/MIME application/pkcs7-mime encrypted message
> >    John Pawling: tested OK.
> > 
> > 6.9 EnvelopedData with All Recipient Types
> >    John Pawling: tested OK.
> > 
> > 6.10 EnvelopedData with KARI RC2 Encryption
> >    John Pawling: tested OK.
> > 
> > 6.11 EnvelopedData with KEK 3DES Encryption
> >    John Pawling: tested OK.
> > 
> > 7. Digested-data
> >    Blake Ramsdell: tested OK.
> > 
> > 8. Encrypted-data
> > 
> > 8.1 Simple EncryptedData
> >    Blake Ramsdell: tested OK.
> > 
> > 8.2 EncryptedData with unprotected attributes
> > 
> > 9. Authenticated-data
> >    There are still no examples in this section.
> > 
> > 10. Key Wrapping
> >    John Pawling: tested OK.
> > 
> > 10.1 Wrapping RC2
> >    John Pawling: tested OK.
> > 
> > 10.2 Wrapping TripleDES
> >    John Pawling: tested OK.
> > 
> > 11. ESS Examples
> > 
> > 11.1 ReceiptRequest
> >    John Pawling: test failed, has sent new example file.
> > 
> > 11.2 Receipt
> >    John Pawling: test failed, has sent new example file.
> > 
> > 11.3 eSSSecurityLabel
> >    John Pawling: tested OK.
> > 
> > 11.4 EquivalentLabels
> >    John Pawling: tested OK.
> > 
> > 11.5 mlExpansionHistory
> >    John Pawling: tested OK.
> > 
> > 11.6 SigningCertificate
> >    John Pawling: tested OK.
> > 
> > ====================
> > 
> > Everything has been tested by at least one person *except* "8.2
> > EncryptedData with unprotected attributes". If no ones 
> tests this, we 
> > will probably get rid of it. Can anyone whose software handles 
> > EncryptedData please test example 8.2 and let me and/or the 
> list know 
> > the results?
> > 
> > All examples that had test failures have been re-submitted to my by
> > the DigitalNet folks *except* 5.10, which Jim Schaad had a lot of 
> > problems with. Could someone generate a new example of 
> 5.10? It would 
> > be valuable to have it in the document.
> > 
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > 
>