Re: Legal Enforceability of Digital Signatures (was Re: The Argument for Digital Signatures)

On Thu, Nov 3, 2011 at 1:37 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> Yes, but we're not talking about getting rid of server logs and e-mails.
> We are talking about providing digital signatures /in addition to/
> server logs and e-mails. In some cases, server logs and e-mail is not
> enough. Server logs contain IP addresses, which may be firewalled or
> NAT'd. IP addresses also change frequently if one is on a residential
> connection. E-mails can be forged quite easily. Denying the authenticity
> of both is quite easy in a court of law (and is why many of the lawsuits
> in the Napster-era days failed to achieve a legal victory for the
> prosecutors).
>

As an engineer I agree on all accounts. However millions of electronic
contracts are signed each day and they hardly ever have a digital signature
attached to them. The way the world has solved it so far are mainly non
technical, through customer support lines, charge backs etc. None of which
I think are good approaches, but thats the reality right now. I want that
to change as well to create more technically beautiful systems such as
bitcoin, where the only thing valid is a a signature. Real world customer
service as well as courts might not care though.


>
> While an electronic signature /may/ be construed as a
> click-through-agreement on a website - that's not what we're talking
> about here. We're talking about digital signatures, which are provably
> more authoritative than a log message saying that somebody clicked on a
> button. It is far more difficult to forge a digital signature than it is
> a server log or e-mail. It is also far more difficult to deny that a
> digital signature belongs to you since the only person that can
> reasonably create the signature is the person in control of the private
> key.
>
> server logs + e-mail == okay
> server logs + e-mail + digital signatures == stronger evidence
>

I agree in theory.

>
> The important part is the "intent to sign" - but few things are more
> clear about an "intent to sign" than a digital signature. So, while the
> law is broad... it certainly doesn't hurt to be more specific, and in
> this case, it is greatly beneficial to the strength of the contract to
> use a digital signature.
>

See this. Signing something with a digital signature is not in itself
intent to sign:

http://www.financialcryptography.com/mt/archives/000697.html


>
>  In the EU and many other countries there is specific support for
>> Digital Signatures, but most of them build up a complex requirement
>> for a licensed public key infrastructure, that just hasn't been built
>> up even now more than 10 years after the approval of the laws. There
>> is an argument that for places like the EU a traditional Electronic
>> Signature is safer that making up your own PKI.
>>
>
> Could you point to the legislation that asserts this?
>

Here is the actual legislation. I'll try to find a more human readable
overview:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML


>
>  At the very least traditional proof should be stored as well until
>> the judiciary branch becomes sophisticated enough to deal with
>> digital signatures.
>>
>
> The judiciary branch in the US and around the world is already
> well-versed in digital signatures and have been using digital
> certificates and signatures in the court system for years. Here is just
> one example from 2008 where the Nebraska courts adopt digital signatures
> and certificates for internal use:
>
> http://court.nol.org/rules/**pdf/Ch1Art3.pdf<http://court.nol.org/rules/pdf/Ch1Art3.pdf>
>
> "traditional proof" was never in question. This is /in addition to/, not
> /in place of/. However, I hope that I have clearly explained how all
> that is necessary is a digital signature. You could throw out the logs
> and the e-mails and still have a solid case with just a digital
> signature... and the courts would understand the usage of the technology
> because it is an integral part to how many of the electronic court IT
> systems operate today.
>
>  * Secrecy
>>
>> This we don't get for free with Digital Signatures, it introduces
>> even more complexity into it.
>>
>
> I didn't make myself clear. Let me try again:
>
> We need secrecy - that comes first. Since we need secrecy, and thus all
> of the math that comes along with that... the exact same math can be
> applied to digital signatures. PKI is used for both secrecy and digital
> signatures. We need PKI for secrecy first... and because we need PKI for
> secrecy, we get digital signatures for "free".
>

Using https for the transport layer is one thing. Encrypting json messages
is a completely different story.


>
> That is, the second you import the OpenSSL library, you get both
> encryption and digital signatures in the same package.
>
>  It also means that a receipt can't be verified  if the user looses
>> his key.
>>
>
> Receipts are not stored in encrypted form... receipts are encrypted when
> traveling across insecure communication channels. That is the message is
> encrypted, but only while it is in-flight across the network. Receipts
> can always be verified because PaySwarm Authorities are required to keep
> public keys indefinitely. PaySwarm Authorities are also coaxed to
> crawl/backup each others public keys on a regular basis. So, even if
> somebody loses their private key, one can still verify the authenticity of
> the receipt.
>

At which case again we are only talking about https level encryption, which
I don't have any problem with and think should be required.


>
> I'll follow up to the rest of your "Digital Signatures Usability" response
> in a separate thread.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Standardizing Payment Links - Why Online Tipping has Failed
> http://manu.sporny.org/2011/**payment-links/<http://manu.sporny.org/2011/payment-links/>
>
>


-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking