Bob,
Here are some comments on portions of you message:
The issue that I was trying to address was how to mitigate the risk
associated with the creation and existance of a private key (which
could be stolen, perhaps by means of a virus running on my less
than A1 secure PC), together with a public key certificate which
(allegedly) binds that key to "me." In particular, we are trying to
decide
whether PEM can reasonably be fielded for commercial purposes with a
sotware implementation on an untrusted PC, or whether we must go to
a smart card imploementation and even consider biometrics for certain
users.
Although I would hope that the certification policy established
by the Policy Certification Authority would address this issue,
in fact the draft RSA Commercial Hierarchy I have reviewed
as part of our deciding to purcase a Certificate Issuing System
does not say anything about limitations of liability. I am also
not aware of any other PCA having published their policy.
No question that a smartcard or other hardware implementation that
protects the user key would be much better than a software-only
implementation. PCAs are free to establish a wide range of policies
and maybe some will require hardware implementation by end users as
well as by organizations.
(As an aside, how will people be made aware of the PCA's policies when
they go to validate PEM messages in the future? What happens
if the policy changes? I would assume that this would cause the PCA to
issue a new set of certificates for all of its CAs, assuming that they
will agree with the new policy. If not, and even if they do, what a
mess!)
Mike Baum and I have been discussing the implications of PCA policy
changes. I think one has to consider such changes on a case-by-case
basis. For example, if a PCA substantively relaxed user or
organization authentication requirements, it might be unfair to the
user community to just publish a revised policy and hope that user's
fetch it and become acquainted with the new policy. Rather, it would
be appropriate for the organization operating the PCA to establish a
new PCA with the new policy and have organizations/users move to this
new PCA (if the wish) or move to another PCA that is more in line with
the old policy (if the PCA decides not to continue to offer the old
policy. Note that in either case only the organization certificate
(issued by the PCA) needs to change; the user and subordinate
organization certificates can remain intact. In general, I'd argue
against a PCA making a substantive change to its policy while keeping
the same PCA name and existing certificates (issued under the old
policy) in place. At a minimum, the PCA should indicate effective
lifetime of the policy as part of the document (oops, we forgot to
explicitly require that). In addition to publishing the PCA policy
statement as an informational RFC, a digitally signed copy will be
online. A good PEM implementation should display the PCA name (e.g.,
local alias or full DN) as well as the recipient or originator DN when
sending or receiving mail. Jeff Schiller once suggested that a MAC
PEM implementation shuld allow a user to retrieve the policy statement
for the PCA and display it upon demand, as a reminder.
My point is that since the X.509 certificate does not provide any
mechanism for limiting the liability associated with the use or
alleged use of a digital signature, and since the claim of the
cryptographic community (myself included) since the invention of
public key cryptography has been that digital signatures should be far
MORE reliable than conventional written signatures, the existance of a
digitally signed document may be interpreted by the courts and public
opinion as having satisfied a higher level of assurance, amounting to
a prima facie case, than would a conventional signature. the burden of
proof would then fall on me to disprove the accusation--a very
difficult task.
My problem is this: If my digital signature carries more weight (in
some sense) than my written signature, yet my private key can be
stolen more easily (let us argue) than my written signature can be
forged, then I have a serious liability and no way to control it.
On the surface, it would seem that the least a digital signature
should imply is attribution, for what else are they good for?
I think the issue again here is that X.509 certificates provide
authentication, not authorization or declaration of fiduciary
responsibility, etc. Other types of signed data can supplement an
X.509 certificate to provide these other functions. Because these
other functions are varried and growing, it is not easly to anticipate
their requirements and provide for them in a single certificate.
Moreover, different authorities might be appropriate to issue different
types of certificates, further arguing against a one-certificate size
fits all approach.
<much omitted text>
Finally, the rest of your message deals with some legitimate concerns
about the liability associated with signing things. In part this is
an area where PCAs will be able to decice what services they offer and
we will just have to see what happens. In other instances, I think
that the certification you are imagining is beyond the pale of the
PCAs that are likely to arise for PEM and other types of CAs, signing
different type sof certificate, will arise to fill this need if it
turns out to be significant. I fully expect people will sign and send
email without giving much thought to the semantics, and that will
constitute a precedent that makes it hard to legally attribute much to
simple email signatures without some overarching framework, which is
beyond the scope of what we have tried to establish for PEM.
Analogously, I used to sign rental car agreements without reading the
fine print on the back. (I now don't have to do that each time
because I signed a document saying that I would not have to sign each
time ...). If push came to shove, I would plead that it is
unreasonable to have expected me to read the fine print, that nobody
does, and that my signature really applied only to the parts of the
contract printed in bigger type on the front (and which I was requierd
to initial so that we all knew what the important stuff was!). I think
it would have been a good defense, but, fortunately, I've never had to
use it. I cannot assume that the liability associated with digital
signatures will be any worse. Even if we use smart cards, etc. to
protect keys, without trusted applications I won't really know whether
what I signed is what I saw on the screen, so I will always have that
uncertainty.
Steve