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

["Bonatti, Chris" <[e-mail]>]

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



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