Subject: RE: SMIME-TYPE question

From: Musy Michel-P28089 <[email-masked]>
Date: Fri, 6 Jul 2001 15:12:03 -0700

Jim,

Thanks a lot for the answers to all. I mistakenly thought that the 
Receipt was the signed-receipt, the signature on the receipt is that
of the originator. So the good thing is that a signed-receipt
may contain a label since a receipt is wrapped into a signed data.

About the answer to 2.3 and 2.4 I would disagree at the moment but
of course I can be wrong:
According to the draft-ietf-smime-x400wrap-02, it seems that each
layer of a triple wrapped X.400 are wrapped with a ContentInfo.
Looking at this document in section: 
3.4.1 Creating a Triple Wrapped Message With an X.400 Content,
Step 3. and Step 4. seems to indicate this. Please let me know if 
here also there is something that I missed or misunderstood.
I am including below the text of Step 3., Step 4., and Step 5.

Michel

=============================================================
Step 3. Sign the result of step 2 (the original content). The SignedData
encapContentInfo eContentType MUST contain the object identifier of the
X.400 content. The SignedData structure is encapsulated by a ContentInfo
SEQUENCE with a contentType of id-signedData.

Step 4. Encrypt the result of step 3 as a single block. The
EnvelopedData encryptedContentInfo contentType MUST be set to
id-ct-contentInfo. This is called the "encrypted body". The
EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-envelopedData.

Step 5. Using the same logic as in step 2 and 3 above, sign the result
of step 5 (the encrypted body) as a single block. The SignedData
structure is encapsulated by a ContentInfo SEQUENCE with a contentType
of id-signedData.
=============================================================

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, July 06, 2001 10:27 AM
To: 'Musy Michel-P28089'; 'Ietf-Smime \\\(E-mail\\\)'
Subject: RE: SMIME-TYPE question

Michel,

I will attempt to answer your questions.

> -----Original Message-----
> From: Musy Michel-P28089 [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 9:34 AM
> To: [email-masked]; Ietf-Smime \(E-mail\)
> Subject: RE: SMIME-TYPE question
>
>
> First I'd like to answer Jim's question. Doing so makes me question
> a few things that I thought I knew. Perhaps someone else
> knows all of them.
>
> (1) I thought that according to RFC-2634, a signed-receipt identified
>     with a content-type OID id-ct-receipt is the content by itself,
>     never needs to be wrapped in a signed data, never is encrypted.
>     I thought that there would never exist a signed-receipt triple
>     wrapped. Please comment.

id-ct-receipt is a content type which does not provide any security in
itself.  As such a receipt content is always signed to provide the
origination and integrety on the receipt structure.  Thus id-ct-receipt
would always appear as the encapsulted content of a SignedData structure.
The SignedData structure is then placed in a ContentInfo structure or else
where.

One could then encrypt either the SignedData structure or a MIME wrapped
version of the ContentInfo structure if there was a reason to provide
privacy on the receipt as well.  (One can conceive of a traffic analysis
attack againist the receipt content.)  And of course if it is encrypted then
it could be triple wrapped.

If you have a hard time dealing with the concept of doing a triple wrapped
reciept, think of doing it with a CMC enrollment message.  The same
questions appear there as well.

>
> The following 4 are somehow the same question but still I'd appreciate
> if someone could confirm or correct each.
>
> (2.1) I thought that there would always be an outer layer
> with a Content
>     Info containing precisely the content-type. Can someone please
>     comment?

The outermost layer will be a ContentInfo object for all items that we are
currently dealing with.  It is possible somebody could do somthing with a
SignedData outer most layer, but none of the tool kits I know of will
support this.

>
> (2.2) According to CMS rfc-2630bis, each layer signed-data,
>     enveloped-data, or signed-receipt would be encapsulated in a
>     ContentInfo.

Please provide the section reference for this.  I don't remember seeing
this.  For S/MIME this is a true statement because there is a MIME wrapper
between each layer thus making each layer the "outermost" layer.  This is
not a true statement when looking at the x.400 wrap draft where the MIME
wrapping is omitted for inner layers.

>
> (2.3) For MIME there is the additional inner id-data that does not
>     exist with X.400, but I thought that both X.400 and MIME use
>     the outer ContentInfo wrapping. Please comment.

This is true only for the outermost layer, not for inner layers.

>
> (2.4)I thought that it implies that a signed-receipt also is wrapped
>     in a ContentInfo. Please comment and correct if I am wrong.

You could wrap a signed-receipt in a ContentInfo object, but you would lose
all security services.  Look at section 2.4 (Signed Receipt Creation) in the
ESS document (RFC 2634).

>
> Michel Musy: [email-masked]
>

jim

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 1:40 AM
> To: Ietf-Smime \(E-mail\)
> Subject: SMIME-TYPE question
>
>
>
> I have a general question that I once knew the answer for but
> am  no longer
> sure that is the case.
>
> The SMIME-TYPE attribute was defined so that a mime-level
> processor could
> have some idea of the content type without having to pull
> apart the message
> and look at the contentHint attribute or the innermost
> eContent.  (Or at
> least that is what I remember it as being for.)  This being
> the case, what
> is the correct value of smime-type on a triple wrapped message with a
> signedReceipt as the content?  It is signed-data or
> signed-receipt.  Should
> the answer change if the inner mime-layers were to be omitted
> (relevant for
> the X.400 case).
>
> Does the answer change if you have an encrypted receipt (i.e.
> E(S(Receipt)))
> What is the correct value of smime-type now?  signedReceipt or
> encrypted-data?  Again does the answer change if the mime
> layer were to be
> omitted.
>
> Signed-receipt means that the top level processor knows what
> is going to
> happen before it gets there and can make intellegent decisions.
>
> Signed-Data is "correct" because the encapsulated content
> contained in this
> SignedData object is id-data or MIME content.
>
> NOTE: For the simple case of data (or MIME) content the question is
> accedemic as signed-data and encrypted-data both imply data content.
>
> My original answer was the the correct answer is that
> signed-receipt should
> be propigated up over all of the layers, but I don't find any
> statements
> about this in either the message or ESS RFCs.
>
> jim
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 6 Jul 2001 15:38:36 -0700

Michel,

I understand where you went wrong -- you didn't.  I have seen a later draft
of this document and this has been changed.  Since EncapsulatedContentInfo
and ContentInfo have the exact same content (i.e. an OID and ANY), having
both is actually redunant.  This means that the ContentInfo can be omitted
and just the EncapsulatedContentInfo used to convay the same information.

jim

> Sent: Friday, July 06, 2001 3:12 PM
> To: [email-masked]; 'Musy Michel-P28089'; 'Ietf-Smime
> \\\(E-mail\\\)'