I agree; option 2 is most flexible...
Regards,
Rich
----------
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: ietf-smime(_at_)imc(_dot_)org
Subject: ESS Signed Receipt AuthAttributes Comment
Date: Monday, November 17, 1997 4:33 PM
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.
================================