All,
In a previous message, I proposed changes to ESS Section 2.4, Signed Receipt
Creation, regarding the chain of digests leading to the SignedData/Receipt
signature value. My message included the following concepts that were
previously documented in the CMS/ESS specs:
1) Mandatory inclusion of contentType attribute in authenticatedAttributes
of signedData/Receipt signerInfo (as per CMS, Sec 5.2).
2) Mandatory inclusion of id-ct-receipt OID in contentInfo contentType in
signedData that includes the Receipt content (ESS, Sec 2.4).
3) Recommended inclusion of contentHints with "receipt" set to TRUE (ESS,
Sec 2.4 and Sec 2.10).
In effect, these are three different fields in the SignedData object that
identify the content as being a Receipt. We definitely need to include the
id-ct-receipt OID in contentInfo contentType, but do we also need to include
both the contentType and contentHints in the authenticatedAttributes of the
SignedData/Receipt signerInfo? It seems that the inclusion of both of these
attributes is redundant. Propose that the ESS Sec 2.4 text should be
changed so that it does not recommend that the ContentHints attribute should
be included in the authenticatedAttributes of the SignedData/Receipt
signerInfo. Also, text should be added which states when the ContentHints
attribute should be used. Recommend the following specific changes to ESS:
1) Sec 2.4, Bullet 7: Change to: "7. A signingTime attribute indicating the
time that the signedData/Receipt is signed SHOULD be created and added to
the authenticated attributes of the signerInfo which will eventually contain
the signedData/Receipt signature value. Other attributes (except
receiptRequest) may be added to the authenticatedAttributes of the
signerInfo." contentHints was deleted from the bullet.
2) Sec 2.10, ContentHints section: Change "Messages that contain a signed
receipt MUST include this attribute with the
receipt value set to TRUE." to "When a SignedData/Receipt is encapsulated by
another SignedData object, then the sending agent SHOULD include a
ContentHints attribute (with receipt set to TRUE) in the
authenticatedAttributes of the outermost SignedData object. For example, if
a SignedData/Receipt is encrypted within an EnvelopedData object which is
then signed using an outer SignedData object, then the outer SignedData
object should include a ContentHints attribute with receipt set to TRUE."
Also, I believe that ESS Sec 1.3.4 should be left as is. It implies that a
contentHints attribute does not necessarily need to be authenticated. When
the contentHints includes a contentDescription and receipt set to FALSE,
then it does not necessarily need to be authenticated. I believe that the
ESS spec should continue to include the flexibility to
support that option. When the contentHints includes receipt set to TRUE,
then it should be authenticated.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================