ietf-smime
[Top] [All Lists]

Re: Attribute Certificate(s) in S/MIME

1998-05-06 11:38:54
From: Stephen Farrell <farrell(_at_)baboo(_dot_)sse(_dot_)ie>

The recent draft on "role" names might also be calling for
functionality which can be implemented using ACs.

I guess people will identify other potential uses of
ACs (even limiting ourselves to mail). The step after that
would presumably be to accept or reject the different
scenarios and then consider how best to pack the
ACs with the messages.


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

<Prev in Thread] Current Thread [Next in Thread>