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
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Blake
Ramsdell
Sent: Friday, July 06, 2001 1:06 PM
To: 'jimsch(_at_)exmsft(_dot_)com'; 'Ietf-Smime (E-mail)'
Subject: RE: SMIME-TYPE question
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:jimsch5(_at_)home(_dot_)com]
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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Blake
Ramsdell
Sent: Friday, July 06, 2001 10:54 AM
To: 'jimsch(_at_)exmsft(_dot_)com'; 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:jimsch5(_at_)home(_dot_)com]
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