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

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

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

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

CMS -> S/MIME -> Non-email

And another is:

CMS -> S/MIME -> Email

And combined you might have:

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

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

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

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

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

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

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

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

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

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

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

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

Blake