Steve and George,
In our telephone calls last night you indicated that you thought
we were now on the right track, and that the Legal Notice
and Disclaimer text that I proposed for a PCA was something
that both RSA (as the sponsor of the RSA Commercial
Hierarchy) and a substantial portion of the user community
could accept (in particular the Apple AOCE digital signature
capability, which as I understand has the root key of the RSA-CH
hard coded into it).
You asked a couple of good questions, though:
1. Have we gone too far? Does the digital signature now
mean nothing at all, if the normal or default condition
is that all legal liability is disavowed? Will users continue to
exercise due caution in protecting their private keys?
2. Is there some way that we could facilitate the use
of digital signatures for legally binding purposes
without having to exchange paper documents in advance?
(Recognizing the problem that an electronically witnessed
affidavit might just require the forger to steal two keys
from the same company.)
With respect to 1, I don't think so. We may have sidestepped the
issue of financial or legal liability, but I would certainly expect
that my digital signature would continue to convey whatever
personal, technical, organizational, or moral authority I possess.
If it were misused, I would run the risk of being exposed to obloquy,
shame, and scorn, and someone might even dress me up in a clown
suit and lock me in the pillory! So I would think that people would
continue to be reasonably cautious, as they are with their
written signatures. and I think that is approximately the intent of
most of the business users who are not authorized to legally bind
their company.
However, by specifying only the two conditions -- no liability, and
full liability under certain conditions -- I left out a significant middle
ground, the use of signatures within a company for internal
business purposes. I think we would certainly want to include
such uses within the "normal" scope of the RSA-CH, so that
needs to be fixed. However, misuse of a digital signature
on a time card could constitute fraud, which would have
legal consequences, so we have to be careful with the wording
here. I'll draft a first cut and give it to one of our lawyers for
at least a sniff test.
With respect to question 2, you discussed the possibility of having
the various CAs publish their own policies, saying under what
conditions and perhaps with what DNs they WOULD agree to
be legally bound. You suggested that perhaps RSA could act
as a trusted entity, almost exactly as a civil law notary, by
acting as the repository of the notarized paper documents
and signing the electronic version under the authority of the
RSA-CH PCA. (I think the CAs should sign their own policy
statements, and then have RSA-CH countersign or witness
that signature, but that is a nit.) Presumably the various CA policies
would be publicly available via anonymous FTP, although there
probably are some privacy issues that should be considered?
Some of the alternatives that we discussed were to have individual
CAs become PCAs in their own right, but this was just the
equivalent of the RSA-CH becoming the IPRA. Another alternative
was for RSA to sponsor another PCA, to be used to register CAs
that would support their users being legally obligated, but this
had the drawback of ignoring a substantial population of users
that is expected to start using PEM-compatible signature
techniques (sorry, Doug, maybe you were right -- I now understand
that both Apple's and DEC's implementations may not support
encryption for privacy because of DES export control restrictions.)
One difficulty with all of these schemes is that each organization
would generally have to operate two CAs, one for the general,
not-legally-binding user community, and one for the legally-binding
subset of users. Without having two different PCAs, some type of a
unique naming structure convention would have to be adopted
if we wanted to have the ability to quickly and easily tell which
CA was which. And given all of the theological arguments
about what should, or should not, go into a DN, isn't clear
to me just how a given organization would create an acceptable
unique DN for the purpose of distinguishing between these two
types of CAs. O=XYZ, OU=Legally-binding-CA is almost as bad a
hack as my late (un)lamented OU=Authorized Countersignature
Required proposal.
I would therefore like to suggest another alternative -- have the
Policy differentiate between those users who are not authorized
to commit their company and do not wish to accept any personal
liability for the use of the company-sponsored signature (the
hoi polloi, for short), and those who are duly authorized to sign
(something/anything) for the company, ON THE BASIS OF AN
ORGANIZATIONAL ROLE BEING INCLUDED IN THEIR
CERTIFICATE and vouched for by their organization.
I would NOT attempt to define what particular powers or
authorization is implied by a particular organizational role. In
most cases that should be sufficiently clear from the name of the
role, and any further clarification can be inserted into the
document itself, if necessary. Or let the lawyers and the
purchasing agents work it out if there are any significant questions.
I'm not saying that the various well-structured ANSI X9F1 and
similar certificates won't play a vital role for computer-to-computer
transactions, merely that for human-to-human transactions natural
languages such as English are sufficient and often preferable.
I would also not imply corporate authority or agency just by the
use of a title in the DN. I may not have any legal authority
to bind the company, but if I sign something as a department
manager I think that conveys significant and useful information
about my credibility.
If I understand Mark Wahl, I can combine two or more different
attributes into a multi-valued RDN, as opposed to creating
a chain of RDNs of those values. In this way I believe that is
is possible to include things like titles and common names in
a single RDN.
Therefore, I ought to be able to say (ignoring details of
application syntax):
C=US, O=GTE Labs,
{CN="Robert R. Jueneman" + Title="Mgr, Secure Systems Dept." +
Serial=22934}
Because no organizational role is indicated, I would not have
any authority to bind the company, nor any legal liability
under the proposed policy.
On the other hand, if a certificate contained
C=US, O=GTE Labs,
organizationalRole={CN="Chief Financial Officer +
roleOccupant=
(C=US,O=GTE,CN="Frank Strouse" +
Title="Director, Finance and Administation" +
Serial=007)
}
then the document would be considered to be legally binding
upon GTE Labs. It would bear the signature of the current
occupant of the role of Chief Financial Officer, who by name
is Frank Strouse, the Director of Finance and Administration.
He would probably also have his own individual certificate,
C=US, O=GTE Labs,
{CN=Frank Strouse + Title="Director, Finance and Administration" +
Serial=007}
Mark -- Please correct me if these uses of a nested multivalued
RDN is not correct. I'm also more than a little confused about the
syntax that is used to indicate an organizational role, since an
organizationalRole is an object class, not an attribute.
I don't understand how an organizationalRole would be indicated
if there is no role occupant, because a common name is used to
indicate the role. How would you tell the difference between a
person's name and a role name?
CN="Chief Big Thunder" is a person's name
CN="Chief Thunders Big" is an organizational role? ;-)