Greg,
In light of Tom Jones' observation about culpability of
employees and officers for various wrongdoings they and company
engaged in together it becomes clearer why in many cases it will
be good advice to obtain a certificate not for each person nor
for each role but for each ordered pair [person,role].
X.509 certificates contain only one DN, so the only way to bind an
individual's identity and a role is to construct a DN which
incorporates both. Of course, you would not want a company to control
the private key associated with this certificate, as they could use it
to later forge the individual's signature in that role capacity. If
the user controls the key, upon termination or change of role, the
certificate would be hot listed. With suitable notarization
facilities, to deal with trusted timestamping of signed documents, the
fact that the user still held the key after the hot listing date might
not be a problem. However, this does introduce a discontinuity in the
key used in conjuncction with the role and that is a nusiance. I
suspect companies will feel more comfortable with a scheme in which
procedural controls are used to enforce the individual-role binding,
without disclosing any keys to the user occupying the role.
Here is another. What is the lifespan over which a
signature may be authenticated or a document decrypted? What a
way to issue a stop payment! I take it that the necessity of
finding the certificate where it belongs until the last time
a given document must be subjected to either process more or
less implies that the certificate must identify [person,role].
This applies even after the person has quit, been promoted, or
been fired since the CURRENT mapping of persons to roles should
have no effect on the decryptability of documents written before
that status change. How is anyone going to authenticate an old
document when enforcing a contract on the ex officers of a defunct
company? Can ANYONE ever destroy a certificate? Is this not
tantamount to destroying evidence?
There is a big difference between lifetimes for signed vs. encrypted
data. Once a data item is signed, anyone who wants to validate it
need to acquire a certification path and corresponding CRLs starting
at some commonly agreed upon point, e.g., the IPRA in the PEM system.
For non-repudiation purposes, the signature needs to be registered in
some fashion, e.g., the Bellcore binary tree hash approach or via a
timestamnp notary. Once a user (e.g., a message recipient) has all of
this anciallary data, then he can prove to a third-party that the data
in question was signed by the indicated signatory, irrespective of
what the signer may do to destroy and keys or certificate copies that
he may possess. Thus, the burden to acquire and hold the necessray
ancillary data is on the individual who derives benefit from possesing
a signed data item, not the sender.
The keying material need to decrypt a data item (e.g., a message) is
held by the reciever of the message, and is completely outside the
purview of the sender. So, nothing a sender can do will affect the
ability of a receiver to decrypt a message once the message is in the
hands of the receiver. In the PEM environment, if you want to retain
messages in encrypted form for a long time, and not have YOUR change of
key paris affect your ability to decrypt old messages, then it would
be wise to re-encrypt the DEK under a "storage key" for archival
encryption purposes. The structure of a PEM message makes this an
easy task in which it is not even necessray to re-encrypt the message
content.
Theorem 1: That a certificate, once created, may not be
destroyed unless it can be proven that no document signed
by that certificate will ever need to be authenticated again.
Based on the abive discussion, I think you'll agree that this
conjecture does not apply, since it is the responsibility of
recipeints of signed message to colect the necessray info to be able
to prove the validity of the signature to a third party in the future.
Theorem 2: That a signature does not prove anything about
the [person,role] doing the signing unless it uses a certificate
issued specific to that [person,role], the time and date of the
signature can be established and authenticated, and that the
[person,role] certificate must itself be signed by both the person
and the role controller in such a way that either may invalidate
the certificate for further NEW signatures after a designated time.
What you are trying to capture here has a lot to do with the security
service referred to as "non-repudiation with proof of origin" (see ISO
7498-2 or the chapter on "Architectural Security for the Internet" in
the "Internet System Handbook"). There are lots of requirements which
must be met to achieve non-repudiation, and PEM provides the basis for
the service, but does not provide the full service.
Attempts to prove/disprove th.1 would tell us a great deal
about whether PEM will be very useful in the real world. It would
seem that if provable it implies that the set of certificates will
grow without bounds, particularly if this is not generally realized.
It also leads to interesting questions about culpability of any
entity that destroys or fails to renew a certificate for fraud or
breach of contract.
We already dealt with the inapplicability of Theorem 1, so I don't
think this paragraph requires further discussion.
Th.2 seems central to Tom's (and the Washington Post's)
concerns about proof of date and authorship that would hold up in
a criminal court. Such a certificate embodies an agreement between
two parties to associate themselves in a given relationship at a
given node. The agreement must be authenticable as must be the
TIME PERIOD over which the agreement is valid... yet it seems that
the certificate must outlive the agreement if anything at all were
to be provable later. Unless all this is well defined it seems
unlikely that anyone would be able to prove much.
As noted above, the operative terms here is non-repudiation with proof
of origin. It can be effected using X.509 certificates as a basis for
authentication, CRLs for revocation, possibly other application of one
or more digital signatures applied to a document, conventions about
document semantics, maybe ancillary certificates of a different form
(or some form of signed data item) to express authorization, and a
timestamp notary to fix the time and date of a signature. It's not a
trivial matter to get non-repudiable digital signatures, and PEM does
not provide the whole service, but considerable work on the problem
has been performed and documented.
Steve