From Bob Jueneman:
Charlie,
Maybe you tuned in late, or more likely, the volume of messages has
been so great that you have skimmed some of them.
Let me say again that I am NOT trying to extend PEM to
handle EDI and other similarly structured applications where the
fined-grained access controls provided by yet-to-be-created-
and-standardized authority certificates are presumably the
most appropriate solutions. Those are laudable goals, perhaps,
but I would be content to merely handle routine business letters
for now.
No, I have been following this list for a couple of years and have not
missed any messages on this thread. In a previous reply to a message
that I had posted along similar lines you mentioned that you are not trying
to extend PEM for any particular purpose, and you repeat that here -- BUT
you are. You are trying to put in a mechanism to protect you from those
misuses of a digital signature that you can imagine from your anticipated
uses of PEM. I am suggesting that this is not appropriate because there
might be other possible misuses that you have not anticipated and for which
your mechanism is insufficient.
I WANT my secretary to be able to open and read my mail in my
absence, and to go to someone else on my staff if necessary to
decide how to respond to a question or request from one of my
customers, upper level management, etc. But I DON'T want her to be
able to sign my name to documents for which I alone am resp[onsible
according to company policy.
I don't like having to use a hack like roleName="Valid for encryption
only" -- I would prefer something that more easily machine processable,
But I don't know of any other way to indiciate that although this
certificate is valid for key exchange for encryption, it should not be
considered valid for ANY digital signature. If you can think of a way of
using one certificate and one private key for two different purposes
that are mutually exclusive, I'd like to hear it.
I guess I did not express myself clearly. It is not the provence of PEM
(a secure messaging protocol) to solve this security policy problem.
In fact, the problem cannot be solved by PEM. You can put anything you
want in your DN -- that by itself does nothing to ensure anyone that your
secretary doesn't have access to your "personal and confidential key" and
is using it behind your back. The problem needs to be solved at the trusted
system level by integrating the PEM secure messaging mechanism with other
mechanisms that provide the desired security policy enforcement.
As a hypothetical solution to your problem, an implementation of a PEM MUA
(which encompasses far more than PEM the secure messaging protocol)
running on a trusted system could include an integrated key access module that
would allow you to grant temporary and very specific "rights" to use your key.
This mechanism might work using an elaborate Access Control List so that
you could authorize your secretary to read but not sign documents on
your behalf, or authorize your boss to read and sign documents on your behalf
with the provision that any use of your signature would automatically insert
the string "as signed by XXX on behalf of Bob Jueneman".
In order to ensure trust, we need to provide adequate control over the
access and use of keys, not add unprovable assertions to our DN.
Charlie Watt
SecureWare, Inc.