Scott and Russ,
IMHO, when contentDescription is present and receipt is FALSE, then the
contentHints attribute does not necessarily need to be authenticated. I
believe that the ESS spec should continue to include the flexibility to
support that option.
If contentHints includes receipt set to TRUE, then it needs to be
authenticated. However, this is a problem with the current ESS spec because
it does not include the authenticatedAttributes in the data to be hashed to
calculate the signature value for the SignedData/Receipt, so it is
impossible to inlcude an authenticated contentHints in a SignedData/Receipt.
Therefore, I believe that Section 2.4 of ESS should be changed so that it
includes hashing the authenticatedAttributes included in the SignerInfo
containing the receipt signature value included in the SignedData/Receipt.
This allows the recipient of a signedData/Receipt to verify the authenticity
of the authenticatedAttributes such as contentHints, signingTime, etc. If
people agree with this recommendation then I could draft a new section 2.4
that is similar to the CMS text for hashing either the content or content
- John Pawling