However, as indicated by both Rich Ankney and Denis Pinkas, the originator
may have multiple ACs. It should be up to the originator to indicate which
ones he/she is wishing the recipient to use. The recipient should only be
allowed to use what is possible within the choice of the originator.
I agree with you and Rich and Denis that if the requirement is for the
originator to select at origination time a subset of the attibutes he may
use, then a list of attribute certs is required somewhere in the
message. The question is must this list be signed?
A single attribute containing a list of (issuerName, serialNumber,
hash(issuerPublicKey)) could serve the dual purpose of binding a normal
certificate into the transaction (to prevent spoofing) and to bind
selected attribute certs into the transaction (to prevent third parties
from inserting unwanted-but-valid attribute certs). I support the
definition of such an attribute, as discussed a while back in the
context of shared public keys.
But the operational question remains whether it is desirable (in the
case of a gateway) or undesirable (in the case of an attacker) for a
third party to be able to insert/delete the sender's legitimate
attribute certs from a message. That question doesn't have to be
answered now - if the certlist S/MIME attribute is defined, it can be
used or not as appropriate.
As long as ACs may be carried in CertificateSet, I'm happy.