I think that this discussion is straying into the access control area
(role-based or otherwise).
Jeff Schiller writes:
I suppose that a well integrated PEM and X.500 DUA would, upon message
verification, take the DN contained in the originator's certificate
and use that to look the originator up in the X.500 directory (this is
guaranteed to find one entry). It can then display all of the names
found in the directory entry. Of course this raises the issue of how
much you are willing to trusted the X.500 directory.
Using this technique you could use employee ID numbers as the
distinguishing attributes in your certificates at GTE (i.e.,
C=US,O=GTE,EID=23456) [EID presumably would be an OID for an employee
number attribute] and have a guarantee of no overlap (unless you reuse
employee IDs). Upon verification of a message the X.500 directory
entry for EID=23456 could be queried and all appropriate attributes
displayed, including all names and restrictions that might be placed
on the individual (again you are trusting the directory here).
This is probably the proper way to solve this issue in the long run,
In general (i.e. not just in the PEM context), I am not sure that what
you describe is necessarily the "proper" (by which I assume that you mean
only) mechanism for making the "names and restrictions that might be
placed on the individual" available to a recipient.
Your remarks seem to assume the "pull" access control model. But this
is not the only model. Existing products such as DCE and MaxSix, and
other architectures such as Restricted Proxies and SESAME use a "push"
model for privileges. Given that PEM will likely be used in conjunction
with other elements of a distributed computing infrastructure, it
may be undesirable for an enterprise to have two conflicting access
control models.
Where a PEM mail message is used to request goods or services then
clearly the authorisation or accounting issues need to be addressed,
and concerns in this area seem to underly most of this thread. While
not couched in ECMA Security Framework terms, Robert Jueneman's
"T=Mgr., Secure Systems Dept." or the like exemplifies the model
advocated by proponents of role-based access control (and such
an attribute value assertion would be carried as a privilege attribute
- rather than as part of the DN - in an ECMA/SESAME PAC).
Although the "pull" model of access control may be the only one which
appears to be consistent with current (X.500-oriented) PEM infrastructure,
it doesn't necessarily follow that this is the best model to use. I would
suggest that at least some study is needed of the relative costs
of clients' sending access control information versus multiple server
retrievals of the same information. The current X.509 Certificate needn't
necessarily be a constraint - see the existing work in SC27 on Security
Information Objects, and the recent SC21 request for contributions on
X.509|ISO/IEC 9594-8 Certificate Definition.
However, while this is an interesting subject, since access control is
the first listed of the "concerns ... not addressed" in section 3 of
RFC 1421, it may not be in scope of PEM and this list. It may well be
a subject which the AAC WG ought to address. Nothwithstanding such
organisational concerns, it certainly seems to be inappropriate
to effectively entrench an access control mechanism by default (which
seemed to me to be the intent of Jeff's remarks).
Piers
-------------------------------------------------------
Piers McMahon 16AUG93
ICL
post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email:
p(_dot_)v(_dot_)mcmahon(_at_)rea0803(_dot_)wins(_dot_)icl(_dot_)co(_dot_)uk
OR p(_dot_)mcmahon(_at_)xopen(_dot_)co(_dot_)uk
phone: +44 734 586211 extension 3285
fax: +44 734 855106
-------------------------------------------------------