All,
The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of a Mail List Agent (MLA) including a Mail List (ML)
Expansion History attribute in a SignedData object and a receiving agent
processing that attribute. A single SignedData object can include multiple
SignerInfos each of which could include a ML Expansion History attribute. I
believe that this should be allowed and should be documented in the ESS.
For example, if an MLA needs to relay a message to a ML composed of RSA-only
and DSA-only users. The MLA can include one SignerInfo that includes an RSA
signature value and a MLExpansionHistory attribute. The same SignedData
object could include another SignerInfo that includes a DSA signature value
and a MLExpansionHistory attribute. In this example, the RSA-capable ML
recipients would process the MLExpansionHistory attribute in the RSA-signed
signerInfo and the DSA-capable ML recipients would process the
MLExpansionHistory attribute in the DSA-signed signerInfo. This is true
because a recipient should only process a MLExpansionHistory attribute if
the recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient should not use an MLExpansionHistory attribute which
she can't authenticate.
If multiple MLExpansionHistory attributes are allowed in a signedData
object, then we may want to define some additional rules such as:
1) All MLExpansionHistory attributes included in a SignedData object must be
identical.
2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include MLExpansionHistory attributes. In other
words, there can only be one MLExpansionHistory attribute per
signatureAlgorithm applied to the SignedData.
3) A receiving agent should process the MLExpansionHistory attribute, if
present, in each SignerInfo in the SignedData object for which it verifies
the signature. This may result in the receiving agent processing multiple
MLExpansionHistory attributes included in a single SignedData object. If we
adopt the rule that all MLExpansionHistory attributes must be identical,
then this would imply that the receiving application would process the first
MLExpansionHistory attribute that it encounters in a SignerInfo that it can
verify and then simply ensure that all other MLExpansionHistory attributes
are identical to the first one encountered.
I also believe that we should add a restriction that only one
MLExpansionHistory attribute can be included in the authenticatedAttributes
of a SignerInfo.
I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I believe that it deserves
special attention.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================