[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).
> 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.
> 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.