All,
The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of including security label attributes in a SignedData
SignerInfo authenticatedAttributes. There can be multiple SignerInfos
present within a SignedData object. Each SignerInfo can include
authenticatedAttributes. Therefore, a single SignedData object may include
multiple SignerInfos each of which may include a securityLabel attribute. I
recommend that multiple security labels should be allowed in a single
signedData object (please read the entire message before judging the
proposal).
For example, if an originator desires to send a signed message including a
security label 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 securityLabel attribute. The same SignedData object
could include another SignerInfo that includes a DSA signature value and a
securityLabel attribute. In this example, the RSA-capable recipients would
process the security label in the RSA-signed signerInfo and the DSA-capable
recipients would process the security label in the DSA-signed signerInfo.
This is true because a recipient should only process a securityLabel
attribute if the recipient can verify the signature of the SignerInfo which
covers the securityLabel attribute. A recipient should not use a security
label which she can't authenticate.
If multiple security labels are allowed in a signedData object, then we may
want to define some additional rules such as:
1) All security labels included in a SignedData object must be identical.
(Note that this would limit the flexibility, but also limit the complexity
of constructing and processing security labels.)
2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include securityLabels. In other words, there
can only be one securityLabel per signatureAlgorithm applied to the
SignedData. (Note that this would limit the flexibility, but also limit the
complexity of constructing and processing security labels.)
3) A receiving agent should process the securityLabel 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
security labels included in a single SignedData object. If we adopt the
rule that all security labels must be identical, then this would imply that
the receiving application would perform access control based on the first
securityLabel that it encounters in a SignerInfo that it can verify and then
simply ensure that all other securityLabels are identical to the first one
encountered.
Another alternative would be to prohibit multiple security labels in a
SignedData object. If this solution is selected, then the sending agent
would need to check every SignerInfo that has already been constructed for
the SignedData to ensure that a securityLabel attribute has not already been
included. If this solution is selected, then the receiving agent would need
to search every SignerInfo to determine if a securityLabel attribute is
present. The problem with this alternative is that a receiving agent should
not process a securityLabel attribute unless it has been authenticated, so
if the receiving agent obtains a securityLabel from a signerInfo for which
it can't verify the signature, then it can't authenticate the security
label, so it should not use it. This would happen in the aforementioned
example if only one securityLabel were allowed in the SignedData object.
The security label would be included in either the RSA-signed SignerInfo or
DSA-signed signerInfo, but not both. For example, if the label was included
in the RSA-signed SignerInfo, then the DSA-only recipient wouldn't be able
to verify the signature covering the securityLabel attribute.
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.
================================