Subject: Re: And the definition of non-repudiation is....?

From: "Bob Blakley" <[email-masked]>
Date: Tue, 17 Aug 1999 15:15:48 -0500

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

>This is not what non-repudiation is in business -- what DMS-NR describes is
>simply the assertion of a truth, which is authentication.

Sorry, but your definitions are all non-standard from the security viewpoint,
Ed.
Authentication is *nowehere* defined as "the assertion of a truth".  There's
a wealth of definition, including from ISO, from various national bodies,
and from academic literature.  For a start you might look at :

"Authentication in Distributed Systems: Theory and Practice"
        (Butler Lampson, Martin Abadi, Michael Burrows, Edward Wobber, 1991)

The tautology "1=1" asserts a truth, but authenticates nothing.

>BTW, the sure sign
>that the DMS-NR definition does not define a non-repudiation process is
>the fact  that the signer can NOT deny providing DMS-NR.

It's probably not worthwhile to go much further down the path of this
argument,
but I'll repeat one more time that this definition cannot possibly be right.
The only way one can ensure that the signer can't deny providing DMS-NR is
to kill the signer the instant after signature, and I'm not sure that's
effective
in all cases.  The reason NR is necessary is precisely because the signer
might deny.  If the signer denies, a dispute exists.  If a dispute exists, it
is
arbitrated by some authority.  The authority has rules of evidence.  Using
these rules of evidence, the authority examines the NR evidence, which IN NO
CASE is proof ipso facto, and determines its probative value.  Then, based
not only on the NR evidence, but ALSO on other evidence and on law and
perhaps other bases, the arbitrator makes a judgement.

It would be very nice to imagine that we could produce a technical artifact
that would make the arbitration process unecessary, or just a rubber stamp.
But it isn't going to happen.

>To a bank or in business [cf. Nicholas Bohm, CC'd] , non-repudiation
>means that I can be held liable for a signature I did not make if the
>recipient could not distinguish it from a signature I did make. The
>recipient's trust in what was apparently (but not in fact) my signature
>is therefore held by law to be well-founded.  My trust in the reliability
>of the systems concerned (i.e. my trust that only a signature made or
>authorised by me will be treated as binding on me) is held by law
>to be ill-founded.

The real situation is much more complicated than this.  In some cases
the recipient is out of luck.  In other cases the bank is out of luck.
In yet other cases you're out of luck.  And *all* this is on the basis of
*exactly* the same evidence (your signature) which should demonstrate
why NR evidence is not proof of anything.

>In fact, non-repudiation occurs and is logically granted even if, indeed,
>the signer *proves* (legal, technical, etc.) beyond doubt that it did
>NOT make the signature -- the basic tenet here is that the
>relying-party had (past) to make a decision to accept the signature
>and based (past) such decision on its means to deny signature
>repudiation, which power was granted by the signer.

I don't agree with the terminology yet again.  Non-repudiation *does not*
occur - what occurs is liability for a transaction in the presence of
evidence.

>That is
>why *absence* of the signer's expression of power to grant
>non-repudiation to the relying-party is a sure sign that
>non-repudiation does not exist (since the signer cannot be coerced
>into granting a liability).
>
>I take that non-repudiation in this sense is a desirable feature:  I should
>not be free to deny that I signed what in fact I did sign.  But we need
>to be aware of the other use of this expression (or misuse of it) in
>the sense that a truthful denial is thwarted by a legal affirmation.
>
>The NR "definition" presented by Todd captured IMO the fine points
>of this business scenario and that is why I believe Todd's definition is
>closer to non-repudiation as used in business than the one adopted
>by DMS -- which is simply proof of authentication.
>
>Cheers,
>
>Ed Gerck
>
>

---

From: Ed Gerck <[email-masked]>
Date: Tue, 17 Aug 1999 14:46:06 -0700

Bob Blakley wrote:

> Ed Geerck wrote:

I disagree.  See, for example, Menezes et. al., "Handbook of Cryptography",
page 3:

- entity authentication: *corroboration* of the identity of an entity
- message authentication: *corroborating* the source of information

Now, see Webster:

- corroboration: to support with evidence or authority, to make more certain

Thus, authentication involves two steps:

(i) cognition, in which a trusted value X is acquired (e.g., the identity,
the public-key, etc.) -- cognition defines a "fact", X;

(ii) recognition, in which that trusted value X is used to support with its
evidenciary or authoritative value whether a variable x presented for
recognition is accepted or rejected -- recognition defines whether x
is in accord with fact X.

Thus, authentication asserts a truth -- Webster:

truth: the property (as of a statement) of being in accord with fact or reality.

So, in terms of logic, to authenticate x is to assert the truth of x in the system of
X.

I know that it may sound confusing to say that a "truth" is not an absolute truism
but such is the world of mathematics -- truths can be denied, even if I affirm
them ;-)

So, there is no tautology.  Just a little "getting used to" -- but in math, not in
security definitions.

I suggest you re-read my msg with this explanation in mind.

Cheers,

Ed Gerck