Dave,
I'll answer both your mails in one...
The abstract requirements are:
1. Is it necessary to bind an AC to a specific content or signature (y/n)?
2. Is it necessary to add or remove ACs from a message without invalidating
signatures (y/n)?
I basically agree with your analysis, however, there is a third
possible requirement to be considered:
3. Is it necessary to support controlled delegation of ACs (y/n)?
If the answer is yes, then we need to allow more than just
the AC in the SignedData (or wherever).
And the reason for this is...
One cannot "steal" a public key certificate - certificates are (in
principle) public knowledge, and possession of a certificate does
not by itself convey any privilege whatsoever.
That's right, and if no delegation support is needed then
just sending the AC with an authenticated message is fine.
However, stealing an AC becomes a threat once delegation
is allowed.
Take the following TLS based example, client (C) establishes a TLS
session with intermediate server (IS), which establishes
a TLS session with a final target (T) on behalf of the client.
Now assume that IS and T base their access decisions on ACs
(doesn't matter here how IS and T get the ACs).
Many environments require that the access decision to be made at
T is based on C's AC and not on IS's AC (or maybe both).
For this to happen IS has to pass (a reference to) C's AC to T.
This is where theft of ACs becomes possible - you need to prevent
a bad IS pretending to be acting on behalf of C. There are different
ways to do this, but all depend one way or another on the C giving IS
the right to delegate, e.g. by signing a structure containing C's name,
IS's name, AC issuer/serial, time etc.
Now, I've no idea if such a scenario is relevant to S/MIME, but
I suspect that some CMS consumers may need to support delegation.
If such controlled delegation is required then it isn't enough
just to pass the AC from C to IS, C also needs to (be able to)
give IS the right to delegate and some additional syntax
is required (though come to think of it, it needn't go
right beside the AC - maybe we could define a delegtion control
authenticated attribute which affects how recipients treat
the ACs?).
Regards,
Stephen.
BTW: Just for information, DCE PACs are somewhat like ECMA PACs which
are very like X.509 ACs (see ftp://ftp.ecma.ch/ecma-st/e219-pdf.pdf,
around page 80, the definition of GeneralisedCertificate).