Charlie,
I certainly agree with what you are saying regarding the extensibility
of PEM, or at least the general framework, to build very general,
security-enabled distributed applications.
EDI, crypto-based mandatory (and discretionary) access control,
distributed workflow -- these are all very important applications.
As Rob Shirey will recall, I predicted three or even four years ago
that the PEM implementation would provide the commercial
base and infrastructure to enable all of these applications. In
addition, as I think we are seeing, it will provide some worked
examples for trust models that have been quite difficult to arrive at.
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
one of those organizations, and I think the closest to actually
having something working on a large scale. 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.)
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.
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?
Typically, these rules are spelled out in a number of standard
policies and procedures manuals that assume a certain knowledge
of the corporate culture.
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.
Thanks for your courtesy and suggestions.
P.S. If you have some current product descriptions I'd be happy to
see them.
Robert R. Jueneman
Manager, Secure Systems
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
1-617-466-2820
1-671-466-2603 FAX