All,
The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00), Section
2.4, Receipt Creation, includes a description of how to calculate the
signature value of a SignedData object encapsulating a Receipt content (i.e.
SignedData/Receipt). This process does not include hashing the
authenticatedAttributes taht might be included in the SignerInfo containing
the receipt signature value included in the SignedData/Receipt. The last
sentence of Section 2.4 states that the signingTime attribute should be
included in the SignedData/Receipt. However, ESS, Section 1.3.4. Placement
of Attributes, states that the signingTime attribute must be authenticated.
Therefore, the Section 2.4 SignedDataReceipt hashing process does not
include authenticatedAttributes included in the SignedData/Receipt, yet it
recommends that the signingTime attribute should be included in the
authenticatedAttributes of the SignedData/Receipt. IMHO, this contadiction
needs to be corrected.
Recommend that ESS be changed in one of the following ways:
1) Change last sentence of Section 2.4 to explictly state that the
signingTime attribute should be included in the unauthenticatedAttributes of
the SignedData/Receipt (even though Section 1.3.4 states that signingTime
must be authenticated).
- OR -
2) Change Section 2.4 so that it includes hashing the
authenticatedAttributes included in the SignerInfo containing the receipt
signature value included in the SignedData/Receipt. (Note: The ESS should
also state that a SignedData/Receipt is not allowed to include
receiptRequest or MLExpansionHistory attributes.)
I recommend option 2.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================