Hello,
I have read the s/mime draft (draft-dusse-smime-msg-05.txt) and looked
at the discussion (at www.imc.org).
I have the impression that the proposal not to support the
SignedAndEnveloped content type is actually withdrawn, but can come up
in the final smime v3-spec.
In our department we intend to use s/mime. At the moment we use PKCS#7
with the SignedAndEnveloped content type. To make a quick implementation
we decided not to perform a "nesting" as described in section 3.5 of the
current s/mime-draft.
My first Question is:
Concerning the future v3-spec of smime, will we "fall out of the
standard" ?
Second Question:
If we use the SignedAndEveloped type, what smime-type has to be
specified in the content-type field?
The type "enveloped-data" is for an encrypted PKCS#7-Object and the type
"signed-data" for an signed PKCS#7-Object.
So it may be "signed-and-eveloped-data"??
Last question:
Concering "nesting" of MIME-Entities using the "multipart"-type, what is
the exact message structure when using signed AND eveloped data?
The content-type can't be "multipart/signed", or is it?
What fillers have other parameter and fields (like the
"protocol"-parameter, and so on)?
Please give us an example of the usage (by sending a example message).
Section 3.4.3.3. of the s/mime-draft gives an example of the
"signed"-type only.
Thanks for helping,
Volker Spiegel
------------------------------------------------------------------------------
Volker Spiegel Phone: ++49 391 67
13547
Dept. of Medical Informatics FAX : ++49 391 67
13536
University of Magdeburg
Leipziger Strasse 44
39120 Magdeburg, Germany
email: Volker(_dot_)Spiegel(_at_)Student(_dot_)Uni-Magdeburg(_dot_)de
homepage: http://www.uni-hildesheim.de/~vspi0124
------------------------------------------------------------------------------