[Top] [All Lists]

RE: Signed Label (was RE: 'Signature Purpose' attribute?)

1998-04-14 12:27:03
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