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

Rohan Mahy <rohan@cisco.com> Fri, 20 June 2003 00:38 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26905 for <smime-archive@lists.ietf.org>; Thu, 19 Jun 2003 20:38:58 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K0D7rb010231 for <ietf-smime-bks@above.proper.com>; Thu, 19 Jun 2003 17:13:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5K0D7X2010230 for ietf-smime-bks; Thu, 19 Jun 2003 17:13:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K0D5rb010223 for <ietf-smime@imc.org>; Thu, 19 Jun 2003 17:13:05 -0700 (PDT) (envelope-from rohan@cisco.com)
Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2003 17:15:47 -0800
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5K0D1EP027153; Thu, 19 Jun 2003 17:13:01 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH99276; Thu, 19 Jun 2003 17:06:50 -0700 (PDT)
Date: Thu, 19 Jun 2003 17:14:10 -0700
Subject: Re: proposed addition to application/pkcs7-mime smime parameter
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v552)
Cc: ietf-smime@imc.org
To: Blake Ramsdell <blake@brutesquadlabs.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAGmA5Sbj9PEOOrhFIrl2UHwEAAAAA@brutesquadlabs.com>
Message-Id: <1DA1D30C-A2B4-11D7-8E0D-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


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

>> -----Original Message-----
>> From: owner-ietf-smime@mail.imc.org
>> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Rohan Mahy
>> Sent: Friday, June 06, 2003 7:59 PM
>> To: Blake Ramsdell
>> Cc: ietf-smime@imc.org; rohan@cisco.com
>> 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