From Bob Jueneman:
However, early in the PEM development effort I argued
unsuccessfully for separating the decryption keys and the
signature keys (and in fact using separate algorithms, but
that is a separate issue). My justification was that I might
want my secretary or someone I appoint as acting manager
to be able to read my mail while I am on travel or vacation or ill,
but I would not want them to be able to sign my personal
name, or even my role name. Even with a formal delegation
of authority, good business practices require that the individual,
not just a role, be held accountable for any official actions.
So my secretary or the acting manager should sign using their
own name, and perhaps say something to the effect "Forwarded
in the absence of Joe Blow to avoid delay, signed, Betty Boop,
Secretary to Mr. Blow." Unfortunately, if they can read my mail
they can also sign my name, so this becomes very awkward to
administer.
..
..
..
So I can foresee something like the following being commonplace:
C=US, O=GTE, OU=GTE Labs,
{CN="Secure Systems Dept., Attn: R. Jueneman",
roleName="Valid for encryption only"}
and
C=US, O=GTE, OU=GTE Labs,
{CN="Robert R. Jueneman", Title="Mgr., Secure Systems",
roleName="For Company Confidential correspondence
and official signature use only"}
and
C=US, O=GTE, OU=GTE Labs,
{CN="Robert R. Jueneman",
roleName="Private and personal correspondence"}
Bob:
I understand what you are attempting to do and agree with the need to
establish the levels of authority and liability to be associated with
a digital signature. But I disagree with your proposed solution for
two reasons:
a) It ties a security policy to a security mechanism.
b) It doesn't solve the problem.
PEM is a mechanism for exchanging messages using cryptographic procedures
to enhance the security (authentication, integrity and confidentiality)
of standard message exchange. How much faith you place in this extended
security is dependent upon the form of key management, the size of the
keys, and the specific algorithms being used. What actions you choose to
take upon receipt of a protected message depend upon the application making
use of the messaging mechanism, the contents of the message, the security
services applied to the message, the strength of the mechanisms used to
provide those services, and the specific security policies being enforced
by the application and the systems upon which it is running.
If we are to provide an infrastructure that is generally useful to a wide
range of applications operating in a wide range of environments, then it is
very important to keep the secure messaging, key management and security
policy components separate. Trying to kludge the DN used by PEM to limit
the applicability of a signature forces security policy into the generic
message passing mechanism. As this method of authorization is probably
insufficient for many potential uses of PEM, adding support for it would
add a lot of baggage that is not applicable in the general case.
This problem of extra baggage ties in with the problem that extended DNs
really don't solve the problem, for the security policy that you want to
enforce is most likely tied to the specific application making use of PEM.
What you will wind up with using your proposal is something like:
C=US, O=GTE, OU=GTE Labs,
{CN="Robert R. Jueneman", Title="Mgr., Secure Systems",
roleName="For Company Confidential correspondence
and official signature on all internal matters concerning
project XXX; not valid for representation of any GTE corporate
positions outside of GTE, except for matters dealing with the
Navy's YYY project; for use with EDI transactions not exceeding
$5000, but may be used for EDI transactions up to $10000 if
countersigned by the GTE ZZZ role; ... "}
I am sure you have many responsibilities, and that these responsibilities
change constantly. How can you encode all of these responsibilities into
a DN such that the DN (and therefore your certificate) do not change with
each change in responsibility, and such that it keeps your legal department
happy?
I am much more comfortable using the certificate simply to bind your name
to your signature, as others have strongly suggested. I would suggest
solving the authorization problem through a separate mechanism. This
allows the possibility of each application using a mechanism meeting its
requirements. For the EDI problem, each organization using EDI might maintain
a list of DNs authorized to make EDI transactions along with any $$ limits or
counter signature requirements (signed by some individual or role with
recognized authority, e.g. VP of Finance). In verifying an EDI transaction,
you would then check the signature chain, the CRL lists, and then retrieve
and check the client's authorizations. The first two would be provided by
PEM, the later would be built into the EDI application itself, where it
belongs.
In your example above you allude to an even more serious problem than
that of distributing authorizations -- that of establishing how much to
trust a signature in the every day work environment. As I mentioned
above, one of the components in establishing trust is key management.
The PEM infrastructure provides a mechanism for linking a private key
to a DN, but cannot control who has access to that key. This can only
be controlled by the specific implementation of PEM relying upon the
security provided by the underlying OS and hardware, as well as strict
observance of procedural controls by all users. Thus the level of trust
that you can place in a received message is only as great as the least
trustworthy component on either side of the exchange having access to
either the message in clear text or the keys used to protect and verify
the message. For example, using a TCSEC A1 hosted smart card system
with biometric I&A is only slightly more secure than a DOS system without
the smart card and biometrics if the A1 procedural controls are lax, for a
simple Trojan Horse MUA can easily trick the smart card into signing
anything.
I don't believe that these problems are something that should paralyze
PEM. After all, with today's technology, a digital signature can be
far more secure than a handwritten one. It is not very difficult
to scan in a handwritten signature and laser print it on top of an
arbitrary document such that only an expert could detect the deception. It
is also not that difficult to design an EDI system using a combination of
software, hardware and physical security techniques (along with sufficient
$$$) that is essentially impregnatable (although there might be a few
quibbles with its "usability").
One reason that I like the suggestion above for an application specific
authorization service is that it allows each organization to explicitly
state the level of liability that they are willing to assume for each
use of a signature. In the example, a signed list of authorized DNs and
limitations is a statement that an organization will honor all EDI contracts
that meet the specified signature requirements. If the organization posting
such a statement chooses not to provide adequate security for its internal
EDI subsystem, then it, and it alone is liable for the consequences.
Charles Watt
SecureWare, Inc.