I have read the ESS document (SMIME V3). It is clearer to me than before
that the ESS signed-receipt must be modified to support
receipt-status-codes along the lines of RFC2298 before it is allowed to
move up the RFC track. It will be of little use to applications unless
this functionality is added.
I would be no problem to define a new attribute which is carried in the
signed-receipt which shows status that could be used by applications.
Status such as "deleted", "processed", etc.
Additionally, the draft should clearly state that the preferred method of
signing a document is "multipart/signed" and the PKCS7 signed is optional.
Best regards,
Rik Drummond
Chair, IETF's EDIINT WG - Secure EDI over Internet Workgroup
Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be
authenticated, while authentication is optional for others. The following
table summarizes the recommendation of this profile.
| |Inner or |MUST be
Attribute |OID |outer |authenticated
------------------|-----------------------------|----------|-------------
contentHints |id-aa-contentHint [ESS] |either |no
contentIdentifier |id-aa-contentIdentifier [ESS]|either |no
contentType |id-contentType [CMS] |either |yes
counterSignature |id-countersignature [CMS] |either |MUST NOT
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |yes
messageDigest |id-messageDigest [CMS] |either |yes
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|yes
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|yes
receiptRequest |id-aa-receiptRequest [ESS] |inner only|yes
signingTime |id-signingTime [CMS] |either |yes
smimeCapabilities |sMIMECapabilities [MSG] |either |yes