ietf-smime
[Top] [All Lists]

Re: ESS EncapsulatedContentType

1998-02-26 09:11:46
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)

I respectfully disagree with Dave that contentType should be removed from
the Receipt content syntax.  It is included in the signed receipt to assist
the application that must validate the signed receipt with the process of
identifying the original message (or hash of the message) that requested the
signed receipt.  The original message (or hash of the message) is required
to validate the signed receipt.  The Receipt contentType will especially be
valuable to apps that must manage contents of multiple types.  Therefore, I
believe that contentType should be retained and that it should be changed to
a mandatory field which will always contain the value copied from the
signedData encapContentInfo eContentType field of the message requesting the
signed receipt.


I don't object to keeping contentType in Receipt if it serves a purpose.
However, I still don't understand what the purpose is.  Currently, the
eContentType field of the innermost signed data will *always* contain
id-data, no?  If Russ' proposal to define 4 additional OIDs for X.411
builtin message types, or my (as yet unproposed) proposal to define
a single id-data-x411 OID for X.411 messages is adopted, there will
be at most a few eContentType values.  In practice, a single user
is not likely to have both S/MIME and X.411 original messages awaiting
receipts, so the contentType field in the Receipt will be totally
useless in distinguishing which message the receipt applies to.
At best, it could only help distinguish between S/MIME and X.411 messages.

Even then (if there were multiple content types), what is the purpose
of including contentType in the Receipt?  The Receipt
signedContentIdentifier uniquely identifies the message to which the
receipt applies, so the UA only needs to validate the receipt against
that single message.

What am I missing?


<Prev in Thread] Current Thread [Next in Thread>