So although I am ignorant of the details of the ECMA Privilege
Attribute Certificate, it and similar certificates that X9 and X12
have been developing sound like quite reasonable approaches,
and more power to them.
There comes a time, however, when you have to shoot the
designers (after first shooting the architects and the lawyers)
and ship the product. That is where we are today. I am therefore
not trying to redesign or fix PEM, I merely want to use it, just
for what it was designed for -- encrypting and signing email.
But in the meantime, I don't want to buy into more liability or risk
than we can afford.
For that reason, I am not trying to cram authorizations into
the DN per se. Rather, I am trying to force a highly visible
DISCLAIMER of any authorization into the digital certificate,
which is the only place I can put in where my forger will be forced
to use it. And unfortunately, I am caught in a standards box of
an X.509 certificate that doesn't accomodate what is needed,
and a PEM standard (and PEM implementations) that insist that
I have to use X.509, even though the PEM RFCs don't define a
minimal or suggested set of attributes.
Let me say it one more time:
PERMISSIVE AUTHORIZATIONS ONLY WORK IF THE DEFAULT
IS NO AUTHORIZATION.
]
Otherwise they only add to your liability, instead of subtracting from it.
That is why we have to put a disclaimer in the X.509 certificate, not
some other certificate, and at present the DN is the only place it can go.
I have gone over this again and again, and I don't feel that there is
any other solution within the current PEM environment. And at least
for now, saying "don't use PEM" or "you shouldn't really worry about
legal issues" or "wait for a couple of years until all this solidifies"
are all nonstarters. We want to do it now, using the available tools.
My concern about what you are suggesting is that liability (or
any authorisation concerns) are not within scope of PEM.
I don't see why any opportunistic lawyer can't just be told that
there is a difference between authentication and authorisation, and
that any claims based on a confusion of the two are void given the
clear disclaimer in RFC 1421 that authorisation facilities are NOT
part of the delivered facilities of the PEM technology. Why do you
need a statement from [P]CA or a certificate to re-state what is
in the source document?
I believe that until distributed access control technology is deployed
the solution to your problem lies within the same administrative
procedures as are used for current paper mail.
E.g.: when I am able to sign off certain documents on behalf of my company,
the certificate which links my "analogue" signature to my name is not
remotely adequate information to inform any access decision functions.
The mechanism we use (and GTE may obviously have a different model) is
that authorised signatories also get issued a 2nd "certificate" which says
how much money they can authorise in overtime, expenses, advances, capital
expenditure etc. This certificate is transmitted to recipients of signed-off
documents so that they determine whether to authorise.
So, a certificate which tells you, a recipient of my PEM message,
that a trusted third party vouches for my signature is only part of the
story. To me it is superfluous to note in that certificate that
my access rights are limited because everyone's access rights are
limited.
If I have argued with
some of the PEM developers on occasion, it is precisely because
I have been trying to push that larger vision (not to imply that others
don't have a similar vision, just that they have been more focused.)
I was happy with Jeff's reply that use of the X.509 certificate for the
binding of a user's key to her DN wouldn't preclude use of a PAC for
assertion of privileges. I agree with the spirit of Charlie's suggested
authorisation extensions, but would add that use of an on-line CA
(like the DCE PS) would be needed to protect the PAC in environments where
symmetric key distribution technologies like Kerberos are in use. There are
also a number of other areas which need study for integration of access
control into PEM, but as I noted in my reply to Jeff's remarks, there
is a scope statement in RFC 1421 which clearly confines the PEM "vision"
to a certain set of facilities. One is therefore hesitant to advocate
extensions - unless there is other interest in the community. (Also, as
I haven't yet had time to read all of the pem-dev archives, I am wary
of venturing into areas that have already been previously discussed ...!).
We have initiated a pilot project in GTE Labs precisely to develop
the infrastructure necessary to support these larger initiatives.
We are going to be signing timecards electronically, not because it
will save money -- it will probably cost more than using a pen
and having a service bureau key the data -- but because everyone
understands how timecards work and yet the auditors, legal folks,
etc., will all have to get in the act. In addition, as a Lab, we
do a lot of our daily work via email, and issues of both proprietary
data protection and authentication are important.
Do you address access control in your project?
However, the problem that I have is that I am trying to apply digital
signatures to the mass of business correspondence that falls
in between the well-structured EDI and ANSI X9F1 tranactions and
the casual, "what me worry" type of email, in an environment where
we can't (yet) assume that smart cards and other mechanisms
are sufficiently available or affordable.
In this type of an environment, I can't even encode a user's
credentials very easily in English, much less ASN.1. What is
the ASN.1 encoding for what a manager or a director does?
Well, the ASN.1 definition of a SecurityRole as we see it is:
Security-Role-Attribute ::= SEQUENCE {
attributeType Identifier, -- { ecma-secos-att-privilege 1 }
attributeValue SET OF SEQUENCE{
definingAuthority [0] Identifier OPTIONAL,
roleValue [1] IntegerOrString
}
}
--
-- A role can simply be a job function such as "director", "manager" or
-- "clerk" which can be used as part of an access control decision
-- (e.g.: through via a role ACLE in a conventional extended POSIX/DCE ACL).
--
-- The type or scope of the role is optionally given by its
-- defining authority. For example, for a role type of
-- "purchasing", there are a number of specific job functions
-- such as "requirements specification", "contract definition",
-- and "logistics coordination". Each such role would have the
-- same defining authority: "purchasing".
--
-- Note that the syntax of defining authority also
-- permits, but does not require, the defining
-- authority to be the fully distinguished name of the
-- type of organisational position being described
-- by the role attribute. For example, for the same defining
-- authority = C=US; O=Acme Corp.; OU=Purchasing, there
-- could be a number of different specific roles:
-- RN=requirements specification
-- RN=contracts definition
-- RN=logistics coordination
-- This enables a hierarchical definition of a role to be
-- constructed which can directly reflect the structure of large
-- organisations
Typically, these rules are spelled out in a number of standard
policies and procedures manuals that assume a certain knowledge
of the corporate culture.
I would suggest that you may benefit from technology which allowed the
implementation of an access control policy which could reflect the
roles which exist in your enterprise.
The ECMA framework and SESAME implementation is one such technology
(even if it is multi-vendor and standards-based and hence should be
some way down the track!). As there is increasing interest in
role-based access control, I suspect that there will
increasingly be vendor-specific solutions in this area too.
I certainly understand that various mechanisms have been proposed
by a plethora of different (and sometimes incompatible) standards
bodies that are rightfully pursuing their own agendas. PEM is
PEM is
one of those organizations, and I think the closest to actually
having something working on a large scale.
While this is true, technologies which support distributed authorisation
models aren't that far behind.
If you want to implement a distributed security infrastructure, you
can purchase DCE from many different vendors, or use vendor-specific
but widely used solutions such as MaxSix from SecureWare, Netware
from Novell etc.
Or, ... while most of the plethora of standards may well be at some remove
from implementation, I know at least that elements of the ECMA Security
standards are being implemented as I am rather close to this activity in
the SESAME project!
To facilitate interoperability, we'll be publishing information to
the community on our protocol implementation profile. This won't
get done until some administration issues (like confirmation
of our object identifier assignments etc) are resolved, and I can
find the time to convert my design papers from WFW to ASCII :-(.
However I can send you information if your're interested.
P.S. If you have some current product descriptions I'd be happy to
see them.
See remarks above. I am happy to send you material on ECMA and/or SESAME,
and I also don't think you will find any difficulty in getting
a bespoke or proprietary solutions to your requirements (although you
would probably be stuck with access controls based on identity or
group affiliations with most current offerings on the market).
However, if you don't want to be locked into a specific vendor, or
if interoperability is desired, then it might be worth soliciting
interest in a new work area which addresses your authorisation
concerns to be addressed by the PEM and/or AAC WGs. I think that
the latter WG would in any case benefit from some additional focus
(say: implementation of role-based access control in large networks).
I don't know how work items are initiated, though I assume that
Steve Kent or Steve Crocker could advise - but only if this seemed
interesting to a sufficient number of people.
Piers
-------------------------------------------------------
Piers McMahon 18AUG93
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
-------------------------------------------------------