[Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

[Ian Grigg]

Ed Gerck wrote:


> Likewise, in a communication process, when repudiation of an act by a party is
> anticipated, some system security designers find it useful to define "non-repudiation"
> as a service that prevents the effective denial of an act. Thus, lawyers should
> not squirm when we feel the same need they feel -- to provide for processes
> that *can be* conclusive.

The problem with this is that the squirms happen at
many levels.  It seems unlikely that we can provide
for conclusive processes when it comes to mixing
humans and tech and law.  If we try, we end up with
the Ross Anderson scenario - our work being trashed
in front of the courts.

Hence the need for a new framework.  Talk of non-
repudiation has gone to the extent of permitting
law makers to create new presumptions which - I
suggest - aren't going to help anyone.  For example,
the law that Pelle posted recently said one thing to
me:  no sane person wants to be caught dead using
these things:

   Pelle wrote:
   The real meat of the matter is handled in Article 31 (Page 10). "Guarantees 
   derived from the acceptance of a Certificate":

        "The subscriber, at the time of accepting a certificate, guarantees all the     
        people of good faith to be free of fault, and his information contained 
        within is correct, and that: 

        1. The authenticated electronic company/signature verified by means of this 
        certificate, was created under his exclusive control.

        2. No person has had access to the procedure of generation of the electronic 
        signature.

        3. The information contained in the certificate is true and corresponds to 
        the provided one by this one to the certification organization."


Is that for real?  Would you recommend that to
your mother?  I wouldn't be embarrassed to predict
that there will be no certificate systems in
Panama that rely upon that law.



I think aiming at conclusivity might be a noble
goal for protocol designers and others lower
down in the stack.  When humans are involved,
the emphasis should switch to reduction in costs:
strength of evidence, fast surfacing of problems,
sharing of information, crafting humans' part in
the protocol.

When I design financial systems, I generally think
in these terms:  what can I do to reduce the cost
and frequency of disputes?  I don't aim for any
sort of conclusivity at any costs, because that
can only be done by by setting up assumptions
that are later easily broken by real life.

Instead, I tend to examine the disputes that
might occur and examine their highest costs.
One of the easiest ways to deal with them is
to cause them to occur frequently, and thus
absorb them into the protocol.  For example,
a TCP connection breaks - did the packet get
there or not?  Conclusion: connections cannot
be relied upon.  Protocol response:  use a
datagram + request-reply + replay paradigm,
and lose a lot of connections, deliberately.
Conclusivity is achieved, at the cost of some
efficiency.

Another example - did the user sign the message?
We can't show what the user did with the key.
So, make the private key the agent, and give it
the legal standing.  Remove the human from the
loop.  Make lots of keys, and make the system
psuedonymous.  We can conclusively show that
the private key signed the message, and that
agent is to whom our contractual obligations
are directed.

Technical conclusivity is achieved, at the
expense of removing humans.  The dispute that
occurs then is when humans enter the loop
without fully understanding how they have
delegated their rights to their software
agent (a.k.a. private key).  We don't deny
his repudiating, we simply don't accept his
standing - only the key has standing.

Which brings us full circle to Panama :-)
Except, we've done it on our own contract
terms, not on the terms of the legislature,
so we can craft it with appropriate limits
rather than their irrebuttable presumptions.

>From this pov, the mistake that CAs make
is to presume one key and one irrebuttable
presumption.  It's a capabilities thing;
there should be a squillion keys, each with
tightly controlled and surfaced rights.


iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com