RK
PS. Yes, 877 will be joining 888 by '98. 8 mil per block; 800 exhausted last
year; already **3M** 888s, so the North American Numbering Plan morphs again..
From: Nick Szabo- <szabo-@best.com>
Subject: Re: legal question about certs
To: cme@cybercash.com (Carl Ellison)
Date: Wed, 25 Jun 1997 18:23:25 -0700 (PDT)
Cc: banisar@epic.org, spki@c2.net
Carl Ellison:
>However, there is a theory that for each transfer of rights in one direction,
>there is a transfer of responsibility in the other direction.
>....
>Ron Rivest argues that as cryptographers, all we care about is the rights
>transfer...that the responsiblity transfer is the domain of lawyers.
(Disclaimer: the following observations are U.S.-centric, and IANAL).
In most cases rights and responsibilities are symmetric -- if
Alice has the responsibility to do something for Bob, then Bob has the
right to have that done. But there are wrinkles; for example: a
contract between Alice and Bob might specify Alice has the responsibility
to perform for a third party Charles. Counterparty Bob still holds the
right to have that part of the contract performed; Charles does not.
(The legalese here is that Bob is "in privity" to the contract whereas
Charles is not: Bob can sue Alice for breach of contract but Charles, who
is merely a beneficiary, cannot). To further complicate matters,
there are certain exceptions to the doctrine of privity, which vary
between jurisdictions.
One of the major purposes of security, IMHO, is to minimize
the need for expensive legal intervention, and secondarily to
make that legal intervention as reliable as possible in the
event it is needed. So we shouldn't just fob off major problems to
the domain of lawyers, but rather strive to give the investigators
and lawyers clear evidence to work with before we pass our bits
off to them.
> For example, an attack is envisioned. Bad company, Acme, finds your
> public key someplace from some legitimate cert of yours and generates a
> new cert for you, giving you access to their file system. Someone breaks
> into their file system and does damage, wiping out the audit logs of who
> broke in. So, Acme asks the age-old Perry Mason question: who had keys
> to that door? Your cert (even though you never saw it) is a key to that
> door. That makes you a suspect. If for other reasons you might be even
> the most logical suspect, then you might make it to the top of the police
> list and get severely hassled.
This is a question of gathering and interpreting evidence. Is there
evidence that you asked Acme for the cert? Is there evidence that
Acme agreed to this request by sending you a cert? Is there
evidence that you received the cert? Both sides might be
wise to create audit logs of their communications and require
signatures on these kinds of negotiation messages.
Alternatively or additionally, the subject can agree to counter-sign
the certificate. But even a counter-signed certificate could
have been stolen by Acme or a third party, rather than used
by you. Counter-signing just adds more evidence to be interpreted
in context; it is neither always necessary nor always sufficient
as proof in the kind of situation you describe.
Counter-signatures seem quite desirable, but I don't see a
legal principle requiring them. Furthermore, we can foresee applications
where counter-signatures would be too large a performance hit (e.g., if
the subject is offline when the certificate must be generated), and
applications where issuer, verifier, and subject all agree
that the subject should have plausible deniability.
I conclude that SPKI should make counter-signatures easy to do,
and perhaps strongly recommend them as normal practice, but not require
them.
Nick Szabo-
szabo-@best.com
http://www.best.com/~szabo/