Subject: (Practical) S/MIME certificate chain handling

From: "Julien Stern" <[email-masked]>
Date: Thu, 26 Jun 2003 16:26:46 +0200

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Jun 2003 12:40:30 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Thursday, June 26, 2003 7:27 AM
> To: [email-masked]
> Subject: (Practical) S/MIME certificate chain handling
> 
> 
> 
> Hi all,
> 
> I have a question regarding certificate chain verification 
> when receiving a signed email.
> 
> 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.
> 
> 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) :
> 
> 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
>

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 30 Jun 2003 10:09:44 +0200

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

---

From: "Blake Ramsdell" <[email-masked]>
Date: Mon, 30 Jun 2003 02:15:03 -0700

> Sent: Monday, June 30, 2003 1:10 AM
> To: [email-masked]; [email-masked]
> Subject: Re: (Practical) S/MIME certificate chain handling
> 

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

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 30 Jun 2003 12:35:04 +0200

> 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 ;) ).

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

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

---

From: "Blake Ramsdell" <[email-masked]>
Date: Mon, 30 Jun 2003 15:40:01 -0700

> Sent: Monday, June 30, 2003 3:35 AM
> To: Blake Ramsdell; [email-masked]; [email-masked]

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.

> 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.

> 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 ;).

> (2) the verification information (cert chains, crl, OCSP)

Agreed.

> directories, CRL and OCSP, but they need to know _where_ to 

Agreed.

> 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".

> 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 ;).

> 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

From: "Blake Ramsdell" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Mon, 30 Jun 2003 15:40:01 -0700
Importance: Normal
Sender: [email-masked]

> Sent: Monday, June 30, 2003 3:35 AM
> To: Blake Ramsdell; [email-masked]; [email-masked]

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.

> 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.

> 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 ;).

> (2) the verification information (cert chains, crl, OCSP)

Agreed.

> directories, CRL and OCSP, but they need to know _where_ to 

Agreed.

> 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".

> 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 ;).

> 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-camellia-04.txt
Date: Mon, 30 Jun 2003 07:54:05 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Julien Stern" <[email-masked]>
Date: Mon, 30 Jun 2003 12:35:04 +0200
To: Blake Ramsdell <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (Practical) S/MIME certificate chain handling
Sender: [email-masked]

More generally, we have

--
Julien Stern

From: "Blake Ramsdell" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Mon, 30 Jun 2003 02:15:03 -0700
Importance: Normal
Sender: [email-masked]

<verbatim>

Blake

From: "Julien Stern" <[email-masked]>
Date: Mon, 30 Jun 2003 10:09:44 +0200
To: [email-masked], [email-masked]
Subject: Re: (Practical) S/MIME certificate chain handling
Sender: [email-masked]

Jim,

--
Julien

> > similar alternate system) are widely deployed.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 27 Jun 2003 22:17:37 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 27 Jun 2003 21:06:32 -0700
Importance: Normal
Sender: [email-masked]

> From: Jim Schaad [mailto:[email-masked]] 
> Sent: Friday, June 27, 2003 7:32 PM
> To: 'Blake Ramsdell'
> Cc: [email-masked]
> 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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 27 Jun 2003 19:31:30 -0700
Importance: Normal
Sender: [email-masked]

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

> [mailto:[email-masked]] On Behalf Of Blake Ramsdell
> Sent: Thursday, June 19, 2003 3:51 PM
> To: 'Rohan Mahy'
> Cc: [email-masked]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
> 
> 
> > [mailto:[email-masked]] On Behalf Of Rohan Mahy
> > Sent: Friday, June 06, 2003 7:59 PM
> > To: Blake Ramsdell
> > Cc: [email-masked]; [email-masked]
> > 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
> 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Fri, 27 Jun 2003 18:54:17 -0700
Importance: Normal
Sender: [email-masked]

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

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, June 27, 2003 3:43 AM
> To: Julien Stern
> Cc: [email-masked]
> > 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 
> 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
> 
> 

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: Discussing RTCS
Date: Fri, 27 Jun 2003 14:11:48 -0700
Importance: Normal
Sender: [email-masked]

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 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Fri, 27 Jun 2003 12:40:30 -0700
Importance: Normal
Sender: [email-masked]

Julien,

jim

> similar alternate system) are widely deployed.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'g.lunt'" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Signed Receipts and Mail Lists
Date: Fri, 27 Jun 2003 12:38:16 -0700
Importance: Normal
Sender: [email-masked]

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 [email-masked] in this field and sign with my
[email-masked] certificate).

jim

> [mailto:[email-masked]] 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:
> 
> [email-masked]
> 
> 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
> 
> 

From: [email-masked]
To: "Julien Stern" <[email-masked]>
Cc: [email-masked]
Date: Fri, 27 Jun 2003 10:43:02 +0000
Subject: Re: (Practical) S/MIME certificate chain handling
Sender: [email-masked]

> sending of a full chain, do you think it would be reasonable, and

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

From: "Julien Stern" <[email-masked]>
Date: Thu, 26 Jun 2003 16:26:46 +0200
To: [email-masked]
Subject: (Practical) S/MIME certificate chain handling
Sender: [email-masked]

Hi all,

Thanks for your time.
Sincerely,

--
Julien Stern

Reply-To: "g.lunt" <[email-masked]>
From: Graeme Lunt <[email-masked]>
To: "'Sean P. Turner'" <[email-masked]>
Cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Signed Receipts and Mail Lists
Date: Wed, 25 Jun 2003 08:40:05 +0100
Organization: Nexor
Importance: Normal
Sender: [email-masked]

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:

[email-masked]

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

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Cc: "'Sean P. Turner'" <[email-masked]>
Subject: Working on the agenda
Date: Tue, 24 Jun 2003 15:04:27 -0700
Importance: Normal
Sender: [email-masked]

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 

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Cc: "'Rohan Mahy'" <[email-masked]>, <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Tue, 24 Jun 2003 14:46:13 -0700
Importance: Normal
Sender: [email-masked]

> From: Bonatti, Chris [mailto:[email-masked]] 
> Sent: Tuesday, June 24, 2003 2:20 PM
> To: 'Blake Ramsdell'
> Cc: 'Rohan Mahy'; [email-masked]
> 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

Reply-To: <[email-masked]>
From: "Bonatti, Chris" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: "'Rohan Mahy'" <[email-masked]>, <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Tue, 24 Jun 2003 17:20:21 -0400
Organization: IECA, Inc.
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Blake Ramsdell
Sent: Friday, June 20, 2003 18:13
To: [email-masked]
Cc: 'Rohan Mahy'; [email-masked]
Subject: RE: proposed addition to application/pkcs7-mime smime parameter

> -----Original Message---- 
> [mailto:[email-masked]] On Behalf Of Bonatti, Chris
> Sent: Friday, June 20, 2003 11:23 AM
> To: 'Blake Ramsdell'
> Cc: 'Rohan Mahy'; [email-masked]
> 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

Date: Tue, 24 Jun 2003 14:35:55 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: "g.lunt" <[email-masked]>
CC: ietf-smime <[email-masked]>
Subject: Re: Signed Receipts and Mail Lists
Sender: [email-masked]

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
>
>
>  
>

Reply-To: "g.lunt" <[email-masked]>
From: Graeme Lunt <[email-masked]>
To: ietf-smime <[email-masked]>
Subject: Signed Receipts and Mail Lists
Date: Tue, 24 Jun 2003 14:39:46 +0100
Organization: Nexor
Importance: Normal
Sender: [email-masked]

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

Date: Mon, 23 Jun 2003 15:35:47 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: Ietf-Smime <[email-masked]>
Subject: Re: MLA Expansion History processing questions
Sender: [email-masked]

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

Date: Mon, 23 Jun 2003 15:32:16 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: Ietf-Smime <[email-masked]>
Subject: Re: MLA Processing Questions
Sender: [email-masked]

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
>
>  
>

Date: Mon, 23 Jun 2003 14:49:01 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: Ietf-Smime <[email-masked]>
Subject: Re: Receipt Request Processing Questions
Sender: [email-masked]

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

Date: Mon, 23 Jun 2003 14:47:12 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: Ietf-Smime <[email-masked]>
Subject: Re: Receipt Processing Behavior
Sender: [email-masked]

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
 >[email-masked]
 >
 >Should the receipt be created or not?
 >
 >jim
 >
 >
 >

From: "Blake Ramsdell" <[email-masked]>
To: "'Rohan Mahy'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 20 Jun 2003 15:23:42 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Rohan Mahy
> Sent: Thursday, June 19, 2003 5:14 PM
> To: Blake Ramsdell
> Cc: [email-masked]
> 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

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Cc: "'Rohan Mahy'" <[email-masked]>, <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 20 Jun 2003 15:12:48 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Bonatti, Chris
> Sent: Friday, June 20, 2003 11:23 AM
> To: 'Blake Ramsdell'
> Cc: 'Rohan Mahy'; [email-masked]
> 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

Reply-To: <[email-masked]>
From: "Bonatti, Chris" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: "'Rohan Mahy'" <[email-masked]>, <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Fri, 20 Jun 2003 14:23:10 -0400
Organization: IECA, Inc.
Importance: Normal
Sender: [email-masked]

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:
> 
> >> [mailto:[email-masked]] On Behalf Of Rohan Mahy
> >> Sent: Friday, June 06, 2003 7:59 PM
> >> To: Blake Ramsdell
> >> Cc: [email-masked]; [email-masked]
> >> 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
> 

Date: Thu, 19 Jun 2003 17:14:10 -0700
Subject: Re: proposed addition to application/pkcs7-mime smime parameter
Cc: <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
From: Rohan Mahy <[email-masked]>
Sender: [email-masked]

On Thursday, June 19, 2003, at 03:50 PM, Blake Ramsdell wrote:

>> [mailto:[email-masked]] On Behalf Of Rohan Mahy
>> Sent: Friday, June 06, 2003 7:59 PM
>> To: Blake Ramsdell
>> Cc: [email-masked]; [email-masked]
>> 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

From: "Blake Ramsdell" <[email-masked]>
To: "'Rohan Mahy'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Thu, 19 Jun 2003 15:50:40 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Rohan Mahy
> Sent: Friday, June 06, 2003 7:59 PM
> To: Blake Ramsdell
> Cc: [email-masked]; [email-masked]
> 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

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Date: Thu, 19 Jun 2003 15:42:52 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Thursday, June 19, 2003 10:27 AM
> To: Blake Ramsdell
> Cc: [email-masked]
> 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

Date: Thu, 19 Jun 2003 13:27:04 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Cc: [email-masked]
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Bonatti, Chris" <[email-masked]>
To: "'Pandey, Arun'" <[email-masked]>
Cc: <[email-masked]>
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.
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandey, Arun
Sent: Friday, June 06, 2003 07:33
To: [email-masked]
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
[email-masked] [mailto:[email-masked]] =
<B>On=20
Behalf Of </B>Pandey, Arun<BR><B>Sent:</B> Friday, June 06, 2003=20
07:33<BR><B>To:</B> [email-masked]<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--

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, <[email-masked]>
Subject: RE: Making AES a SHOULD in draft-ietf-smime-rfc2633bis?
Date: Sat, 14 Jun 2003 17:44:38 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Paul Hoffman / IMC
> Sent: Saturday, June 14, 2003 10:51 AM
> To: [email-masked]
> 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

From: "Blake Ramsdell" <[email-masked]>
To: "'Darrell Dykstra'" <[email-masked]>, <[email-masked]>
Subject: RE: Determining if a message has multiple layers without processing any of them
Date: Sat, 14 Jun 2003 17:39:28 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Darrell Dykstra
Sent: Saturday, June 14, 2003 7:43 AM
To: [email-masked]'
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
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Darrell Dykstra<BR><B>Sent:</B> Saturday, June 14, 2003 =
7:43=20
  AM<BR><B>To:</B> [email-masked]'<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--

Date: Sat, 14 Jun 2003 10:51:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Making AES a SHOULD in draft-ietf-smime-rfc2633bis?
Sender: [email-masked]

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

From: Darrell Dykstra <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Determining if a message has multiple layers without processing a ny of them
Date: Sat, 14 Jun 2003 10:43:26 -0400
Sender: [email-masked]

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

------_=_NextPart_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--

From: "Blake Ramsdell" <[email-masked]>
To: "'Alberti Antoine'" <[email-masked]>, <[email-masked]>
Subject: RE: RFC-draft evolutions
Date: Thu, 12 Jun 2003 04:11:39 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Alberti Antoine
> Sent: Thursday, June 12, 2003 3:13 AM
> To: [email-masked]'
> 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

From: Alberti Antoine <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RFC-draft evolutions
Date: Thu, 12 Jun 2003 12:12:46 +0200
Sender: [email-masked]

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: [email-masked]
> 
> 
> 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Ietf-Smime" <[email-masked]>
Subject: MLA Processing Questions
Date: Sat, 7 Jun 2003 15:23:36 -0700
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Ietf-Smime" <[email-masked]>
Subject: MLA Expansion History processing questions
Date: Sat, 7 Jun 2003 14:29:14 -0700
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Ietf-Smime" <[email-masked]>
Subject: Receipt Processing Behavior
Date: Sat, 7 Jun 2003 13:57:26 -0700
Importance: Normal
Sender: [email-masked]

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
[email-masked]

Should the receipt be created or not?

jim

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Ietf-Smime" <[email-masked]>
Subject: Receipt Request Processing Questions
Date: Sat, 7 Jun 2003 12:49:59 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 6 Jun 2003 19:59:22 -0700
Subject: proposed addition to application/pkcs7-mime smime parameter
Cc: [email-masked], [email-masked]
To: Blake Ramsdell <[email-masked]>
From: Rohan Mahy <[email-masked]>
Sender: [email-masked]

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

From: "Pandey, Arun" <[email-masked]>
To: [email-masked]
Subject: Loss of Information while mapping an Internet S/MIME Message to X .400.
Date: Fri, 6 Jun 2003 17:03:25 +0530 
Sender: [email-masked]

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

------_=_NextPart_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--

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: WG LAST CALL: draft-ietf-smime-rfc2632bis-03
Date: Wed, 4 Jun 2003 13:22:07 -0700
Importance: Normal
Sender: [email-masked]

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 

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Date: Wed, 4 Jun 2003 13:16:38 -0700
Importance: Normal
Sender: [email-masked]

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 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-04.txt
Date: Wed, 04 Jun 2003 09:47:53 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-04.txt
Date: Wed, 04 Jun 2003 07:58:15 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: example 5.2 basic signed content RSA
Date: Wed, 4 Jun 2003 02:01:27 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Ronen
> Sent: Tuesday, June 03, 2003 11:56 PM
> To: [email-masked]
> 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

Reply-To: <[email-masked]>
From: "Ronen" <[email-masked]>
To: <[email-masked]>
Subject: example 5.2 basic signed content RSA
Date: Wed, 4 Jun 2003 09:56:09 +0300
Importance: Normal
Sender: [email-masked]

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

From: "Blake Ramsdell" <[email-masked]>
To: "'Jacoby, Jeffrey'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-aes-alg-07.txt
Date: Mon, 2 Jun 2003 12:22:57 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Jacoby, Jeffrey
> Sent: Monday, June 02, 2003 7:30 AM
> To: [email-masked]'
> 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

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Use of the AES Encryption Algorithm in CMS  to Proposed Standard
Date: Mon, 02 Jun 2003 11:09:17 -0400
Sender: [email-masked]

 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.

From: "Jacoby, Jeffrey" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-aes-alg-07.txt
Date: Mon, 2 Jun 2003 07:30:21 -0700 
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Post-last-call status of the S/MIME examples draft
Date: Sun, 1 Jun 2003 11:53:37 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Jim Schaad
> Sent: Monday, May 26, 2003 7:51 PM
> To: 'Paul Hoffman / IMC'; [email-masked]; 
> [email-masked]
> 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
> 
> > [mailto:[email-masked]] On Behalf Of Paul 
> Hoffman / IMC
> > Sent: Friday, May 23, 2003 6:11 AM
> > To: [email-masked]; [email-masked]
> > 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
> > 
>