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

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

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

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

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

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

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

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

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

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

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

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

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

Blake