Subject: proposed addition to application/pkcs7-mime smime parameter

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Jun 2003 19:59:22 -0700

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: "Blake Ramsdell" <[email-masked]>
Date: Thu, 19 Jun 2003 15:50:40 -0700

> -----Original Message-----
> From: [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
> 

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: Rohan Mahy <[email-masked]>
Date: Thu, 19 Jun 2003 17:14:10 -0700

> 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

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 20 Jun 2003 15:23:42 -0700

> Sent: Thursday, June 19, 2003 5:14 PM
> To: Blake Ramsdell
> Cc: [email-masked]
> Subject: Re: proposed addition to application/pkcs7-mime 
> smime parameter
> 

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.

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

> 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 

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.

> 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: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Jun 2003 19:31:30 -0700

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
> 
> 
> 
> 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]>
Date: Fri, 27 Jun 2003 21:06:32 -0700

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

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.

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

> documents). But I think we need as a group to make a decision on what

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Jun 2003 22:17:37 -0700

Blake,

> 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