[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: legal question about certs

(disclaimer: again U.S.-centric and IANAL.  Actually, this whole
discussion has been very U.S.-centric; if we are to constrain
Internet protocols to legal opinion we should at least get opinions
covering the wide variety of jurisdictions that are on the Internet).

Robert Jueneman:
> This is precisely why, in the ABA Digital Signature Guidelines, and in the
> statutes that several states have passed that follows those guidelines,
> there is the requirement that the subscriber (subject) of a certificate
> ACCEPT the certificate prior to it being valid.  

Do these guidlines and laws cover all possible kinds of certificates, or 
just identity certificates for legally binding signatures?

I fear that such laws may constrain general technologies 
(e.g., public key decryption of a hash function of another 
public key), with premature and narrow applications and legal 
interpretations (e.g., idenity certificates for legally
binding signatures).  Hopefully, such laws only specify
what legal and technological conditions must be met to 
for other legal conditions to attain, rather than constraining
what use particular technologies may be put to, because
their inventors dubbed them "signatures", "certificates", etc.

Legal tradition is a deep well of interpersonal "protocols"
we can draw upon to our profit, but we should not let the ABA 
or the legislatures of a few U.S. states dictate technological standards 
for the worldwide Internet.

> ...the subject can disavow any transaction that allegedly
> signed with their key. 

Sometimes this is a good thing.  For example, if the verifier
trusts the issuer, but the subject does not trust the verifier
to keep the transaction confidential, these parties may
agree to provide the subject added plausible deniability via
lack of subject signature.

Bob Smart:
> When you sign someone's certificate giving them rights or
> describing them in some way then there must also be a contract, 
> however informal,

A contract requires consideration: there must be creation of 
responsibilities (with corresponding rights) for both sides. 
Otherwise, we have at best a non-contractual agreement which
may or may not be binding.

Furthermore, contracts and other agreements require a "meeting of the minds", 
two parties coming to an agreement, in which case a subject signature makes 
eminent sense.  Further still, this signature should require manual 
intervention and a non-fraudulent user interface describing the contract.  
An automated "signature" won't do since then there is no meeting of minds.

However, there are a large number and wide variety applications of 
certificates which do not involve forming contracts, and some 
automated applications that do not even involve informal non-legal
agreements.  I again suggest that we not burden very general
protocols with narrow and premature legal interpretations.
I speak as someone who has long promoted the use of cryptographic
protocols to create self-enforcing, counterparty observable, 
third-party verifiable, and protected contracts: see my essay "Smart 
Contracts" at my web site.

Nick Szabo