JOhn:
When the signature is used for co-signing, it would not necessarily contain
a receipt request at all. We need to pick careful wording to allow these
practices to continue. Perhaps we need to say that not all of the
SignerInfos need to include receipt requests, but all of that do conatin
receipt requests mut match.
Russ
At 05:12 PM 11/6/97 -0500, John Pawling wrote:
All,
I like Russ' paragraph in the enclosed message. Russ stated: "Both
SignerInfos can contain the same receiptRequest attribute." Does this mean
MUST or SHOULD? I could think of some bizarre scenarios in which different
signers may wish to require that signed receipts be sent to specific
entities, etc. However, stating "All SignerInfos MUST contain the same
receiptRequest attribute." would simplify processing. I could go either
way.
I agree that a similar paragraph could be applied to the multiple
SecurityLabel and MLExpansionHistory attributes with the exception that we
are requiring that those attributes MUST be identical within a SignedData
object.
Russ stated:
Should we also have a warning here about the receipt policy in the
mlExpansionHistory of the outer signed-data?
I believe that warning is already covered in ESS-00 Section 2.3.
- John Pawling
At 03:28 PM 11/6/97 -0500, Russ Housley wrote:
John:
See a few comments below.
10) Sec 2.2: Please add as last para:
"There can be multiple SignerInfos present within a SignedData object.
Each
SignerInfo can include authenticatedAttributes. Therefore, the syntax
allows a single SignedData object to include multiple SignerInfos each of
which could include a receiptRequest attribute. For example, if an
originator desires to send a signed message requesting signed receipts to a
set of users composed of RSA-only and DSA-only users. The originator's
software can include one SignerInfo that includes an RSA signature value
and
a receiptRequest attribute. The same SignedData object could include
another SignerInfo that includes a DSA signature value and a receiptRequest
attribute. In this example, the RSA-capable recipients should return an
RSA
signed receipt to the originator and the DSA-capable recipients should
return a DSA signed receipt to the originator."
I like the thrust of your paragraph, but prefer a slightly different
approach. Does this make all of your points?
"There can be multiple SignerInfos within a SignedData object. Each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos each with a
receiptRequest attribute. For example, an originator can send a signed
message with two SignerInfos, one containing a DSS signature and the other
containing a RSA signature. Both SignerInfos can contain the same
receiptRequest attribute. Each recipient should return one signed receipt."
If you like my paragraph, then similar words should be used in for comments
32 and 36.
11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
examine the authenticatedAttributes field of the innermost SignerInfo
object
to determine if a receipt is requested." To "Processing software SHOULD
examine the authenticatedAttributes field of each of the SignerInfos for
which it verifies a signature in the innermost signedData object to
determine if a receipt is requested. A receiving agent SHOULD build a
signed receipt for each SignerInfo in the SignedData object for which it
verifies the signature and which requests a signed receipt. This may
result
in multiple signed receipts being constructed and sent for a single
SignedData object."
Should we also have a warning here about the receipt policy in the
mlExpansionHistory of the outer signed-data?
Russ