Subject: RE: SMIME-TYPE question

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 6 Jul 2001 13:05:34 -0700

I believe that if I wanted to see a pretty icon in my mail agent, I would
want to see the one that reflected the fact that it was a receipt, so yes.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, July 06, 2001 1:04 PM
To: Blake Ramsdell; 'Ietf-Smime (E-mail)'
Subject: RE: SMIME-TYPE question

I am unclear, do you believe that an encrypted signed-receipt should have an
smime-type of signed-receipt then?

jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Blake Ramsdell
> Sent: Friday, July 06, 2001 10:54 AM
> To: [email-masked]'; Ietf-Smime (E-mail)
> Subject: RE: SMIME-TYPE question
>
>
>
> To tell you the truth, I've never liked smime-type, and it
> wasn't my doing.
> I think that lgl put this in.
>
> If I had to take a stab at it, I would characterize it as
> being a shortcut
> hint to present to the client, and if it is inaccurate, it
> should have no
> effect on processing.  So if you wanted to provide an icon to
> indicate the
> message type, without tearing through the contents, this
> would be your boy.
>
> Now, I think that only RFC2633 profiles any smime-type (with
> the exception
> of signed-receipt in ESS).  If I had to summarize what went
> in the value and
> when to change the value, I would say "whenever there is
> significant client
> benefit".
>
> I think that the micalg parameter in RFC1847 is in somewhat
> the same boat --
> it's meant to be a hint, the values aren't really well
> specified, and you
> just expect the worst and work it out in processing.
>
> Blake
>
> -----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: Tue, 10 Jul 2001 12:36:44 -0700

Blake,

Based on this I would like to see some text added to the message draft in
section 3.2.2

"In some instances an smime-type will be created that only reflects one
security service (such as certs-only which is only for signed), however as
new layers are wrapped this smime-type SHOULD be propigated upwards.  Thus
if a certs-only message were to be encrypted, or wrapped in a new SignedData
structure, the smime-type of certs-only should be propigated  up to the next
mime wrapper."

jim

> Sent: Friday, July 06, 2001 1:06 PM
> To: [email-masked]'; 'Ietf-Smime (E-mail)'