I am again sorry if I have confused anyone while trying to express my
client's requirements related to ACs.
Of the two requirements I have been trying to get addressed, the first one
is on the binding of a particular originator's AC to a signed S/MIME
business transaction (requirement 1 from David Kemp below) and the second
about the implication on ACs if the CertificateSet in the SignedData
certificates field INTENTIONALLY does NOT include ACs.
For the former, as a business transaction is signed with the originator's
private signing key, to verify the authenticity and integrity of the
transaction, the recipient's application software uses the originator's
public key certificate, which is identified through SignerInfo
issuerAndSerialNumber field of the signed transaction.
However, there are currently no EXPLICIT means to bind a particular AC, of
the many ACs an originator may have, with a signed business transaction to
convey the privilege of this originator. An example of a privilege conveyed
through an AC is: Bob is authorized to approved contract under $1 Million
US for Firm X. The only IMPLICIT means in CMS to bind an AC with a signed
business transaction is to include the particular originator's AC in the
SignedData certificates field. Because of the different version number
allowed by CMS for the SignedData version field, the recipient's
application software would know that ACs were included with this signed
business transaction. However, the originator would have no explicit
guarantee that the recipient's application software would process the
included AC properly. Would the recipient's application software only
verify the signature on the transaction versus the particular originator's
privilege to approved this signed business transaction conveyed through the
bound AC?
Note that I have not suggested to include ACs in the SignerInfo
authenticatedAttributes field of CMS since their current inclusion in the
SignedData certificates field is most appropriate (option 3 from David Kemp
below).
For the latter, if ACs are intentionally NOT included in the SignedData
certificates field, there will than be no means for the recipient to ever
know that a particular AC had been bound to this signed business
transaction, by the originator, to convey the proof of his/her
authorization. Since the SignerInfo issuerAndSerialNumber field is already
being used to identify each originator's valid public key certificate, it
can not also be used for the purpose of identifying the particular
originator's AC. How can the recipient's application software than find and
retrieve the applicable originator's AC?
This is why I have suggested in a previous message that a new CRITICAL
authenticated attribute should be supported by CMS in the SignerInfo
authenticatedAttributes field. This new authenticated attribute would just
be a pointer that UNIQUELY identifies the applicable originator's AC and
would not include the applicable AC. ACs could still optionally be included
in the SignedData certificates field. By being signed by the originator,
this new authenticated attribute would preclude spoofing. This new
attribute would EXPLICITLY identify which particular AC, of the many ACs an
originator may have, MUST be used by the recipient's application software
to verify the authorization service conveyed through the particular
originator's AC bound to this signed business transaction.
This new authenticated attribute addresses all of my client's requirements
related to ACs:
- First, since I have suggested that this attribute should be CRITICAL, the
originator would have an EXPLICIT guarantee that the recipient's
application software would know how to process the bound AC properly,
otherwise the application software would not processed further the signed
business transaction.
- Second, it would allow the recipient's application software to find the
applicable originator's AC if many ACs have been included with the
SignedData certificates field.
- Third, it would allow the recipient's application software to find and
retrieve the applicable originator's AC from the repository where ACs are
published or to find it in the ones the application software may have
cached, if ACs have NOT been included with the SignedData certificates field.
Francois Rousseau
You wrote:
Stephen,
Although putting requirements first and protocol second is a good idea,
paralysis by analysis is a potential bad outcome of that method. It
seems to me that requirements may be stated more abstractly, perhaps
illustrated by specific examples, but that compiling an exhaustive list
of scenarios is not necessary.
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)?
Note that the two requirements are mutually exclusive - no mechanism can
simultaneously satisfy both.
Although Mr. Rousseau originally proposed that ACs be carried in
signed attributes, his Electronic Commerce scenario implies no
requirement for the user to sign the AC:
> Although public key certificates can provide
> such an authorization service directly if privileges are associated with
> this user through the practices of the issuing Certificate Authority, it
> can be more appropriate to dissociate privilege from identity. In such
> cases, the AC can be the means by which the user's privileges are
> expressed. Based on this, ACs are than required to convey, with
> authenticity, integrity and currency, the privileges associated with a
> user, in order that Verifiers can enforce the appropriate Control
Policy on
> signed S/MIME transactions.
And your (Stephen's) mail list scenario has a requirement that users
*not* compute signatures over the ACs:
> firstly, it may be appropriate
> for the mail list to remove the originator's AC (it could be
> usable for lots of things which we don't want the entire list
> to know about) and, secondly, multiple expansions could occur
> meaning that different ACs may be needed at different stages.
Thus we have a negative answer for requirement 1, and a positive answer
for requirement 2. The only reason to collect any more scenarios would
be to find one which not only implies a "yes" for requirement 1, but
which is so compelling that it trumps the requirement 2 scenarios and
leads to a syntax which does not address them.
Note also that any scenario which required the user to sign the AC
violates the fundamental principle that the security properties of
certificates derive from validating the Authority's (CA or AA)
signature, and do not depend on any protection provided by the
repository or the transmission path between the Authority and the
Verifier.
So we have three syntax options for ACs:
Satisfies
Option Reqt 1 2
-------------------------------------- ----------
1. signed attribute in each SignerInfo Y N
2. unsigned attribute in each SignerInfo N Y
3. (unsigned) field in SignedData N Y
As previously mentioned, including all the ACs in SignedData is more
space efficient than including potentially duplicate copies in
each SignerInfo, so I still prefer Option 3, which is the method
CMS currently uses to carry ACs.
Dave Kemp