All,
I agree with the concept of Paul's text that he proposes to add to the
EquivalentLabels attribute proposal. I have a few wordsmithing
recommendations included:
"Before processing an EquivalentLabels attribute, the receiving agent MUST
verify the signature of the SignerInfo which covers the EquivalentLabels
attribute. A receiving agent MUST NOT process an EquivalentLabels attribute
for which the signature has not been verified. A receiving agent MUST NOT
act on an EquivalentLabels attribute which is not signed by an entity that
is trusted to specify equivalence mappings. The process by which the
receiving agent determines if an entity is trusted to specify equivalence
mappings is a matter of local policy. A receiving agent SHOULD process the
ESSSecurityLabel attribute before processing the EquivalentLabels attribute.
If the security policy in the ESSSecurityLabel attribute is understood by
the receiving agent, it SHOULD process that label and ignore the
equivalentLabels attribute."
- John Pawling
Paul's words:
Sorry, I thought that was obvious. A recipient would have a list of trusted
mappers. The new addition now reads:
When processing an EquivalentLabels attribute, the receiving agent MUST
validate the signature onthe EquivalentLabels to determine if there are
additional security labels it wishes to use. A receiving agent MUST NOT act
on EquivalentLabels for which the signature could not be validated or
EquivalentLabels not signed by entities trusted to add or change access
policies; determining who is allowed to specify equivalence mappings is a
local policy. A receiving agent SHOULD process the ESSSecurityLabel before
processing the EquivalentLabels. If the policy in the ESSSecurityLabel is
understood by the receiving agent, it SHOULD process that label and ignore
the EquivalentLabels.