Subject: Re: Definition of technical non-repudiation, was Re: NR -- what the real issues are, and a proposal

From: "Aram Perez" <[email-masked]>
Date: Mon, 23 Aug 1999 11:02:17 -0700

Hi Ed,

[snip]
> 
> In a purely technical way, I agree with the definition of Menezes et al.
> in the HAC and I recently quoted it in an email to this WG [snipped]:
>
> begin quote----------------------------------------------------------
> Subject:  Re: Is this non-repudiation or NR, and why?
> Date: Thu, 19 Aug 1999 16:52:42 -0700
> From:  Ed Gerck <[email-masked]>
> ...
>
> To contrast, compare with Menezes et al., in HAC, page 3:
>
> "non-repudiation: preventing the denial of previous commitments or actions"
>
> which is both legally and technically possible (as a function of how it
> is done) and is in accord with the name -- non-repudiation. Note that
> there is no mention of intent.
> ....
> end quote------------------------------------------------------------

I have problems with "preventing the denial". You can not prevent me from
denying anything. All you can do is disprove my denial. So I don't think
this is a definition of "technical non-repudiation".

[snip]

Regards,
Aram Perez

---

From: Ed Gerck <[email-masked]>
Date: Mon, 23 Aug 1999 11:55:06 -0700

> this is a definition of "technical non-repudiation".

But there are several ways to prevent denial, both technically and legally,
so  I must take issue.  In the interest of dialogue, I need to point out first
that there is often a confusion between "non-repudiation proof" and
"repudiation of a proof" (copied from one of my previous msgs):

 Non-repudiation provides for means (e.g., a contract) which
 preempts repudiation claims if certain criteria are met.  However,
 non-repudiation can be repudiated either by disproving assumptions
 supposed to exist (e.g., that the contract is legal) or by proving acts
 supposed to be absent (e.g., a tort).  Aside from these two possibilities,
 non-repudiation can be enforced according to the criteria agreed
 to in the contract and cannot be repudiated, hence its name.

The same applies technically, where the assumptions supposed to exist
are modeled in the "trusted context" (hardware, software, etc.)
and the acts supposed to be absent are modeled in the "risk factors"
(virus, software error, etc.).  Thus, if what is described in "risk" does not
occur and what is described in "trust" occurs, then  the act is non-repudiable
for a previous act that is in accord to those trust and risk models -- the system
has sucessfully prevented the denial of a previous act.

Second, the impeding problem with "later" in the wording used in PKIX NR, which
is open-ended -- later, when? In five years or in 35 years as German law mandates
for business documents?  When the time arrow is reversed and we look into the past,
then this question is *simple* to answer -- because we know the current time where
non-repudiation is being warranted and we know when that event DID happen.
So, when we say that "a non-repudiation system prevents the denial of previous
acts" -- we are saying it about known acts and known time.  Thus, the two
time views are not equivalent at all.

For example, I grant non-repudiation of my signature to a bank in a check -- but
I grant it so that the bank can prevent my denial of checks I previously signed, not
so that the bank can prevent my later denial of checks.  In fact, I can sucessfully
denial any number of checks to the bank *after* I tell the bank my signature is no
longer valid.  So, I can *always* deny later acts, though I may not always deny
previous acts.

Last, note that "false denial" or "fasely denying" is NOT present in the
defintion by Menezes, which is a problem (either as intent or as pre-defined
logical state) in the current PKIX definition.

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 23 Aug 1999 13:30:25 -0700

>But there are several ways to prevent denial, both technically and legally,

Ed,

I'll bet that in the phrase "preventing a denial", it is assumed that the
term "denial" implies "successful denial".  We can always deny unsucessfully.
In this (common) sense, a "denial" is just an assertion, not an accomplishment.

I am sure that alot of thrashing about is caused by the confusion of terms
like "denial, the assertion" and "denial, the accomplishment".

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Ed Gerck <[email-masked]>
Date: Mon, 23 Aug 1999 20:25:45 -0700

>> Second, note that "false denial" or "fasely denying" is NOT present in the

David Kemp wrote:
>
>The rationale for this attention to the word "false" continues to elude
>me.

This is the legacy paragraph in 2459:

    "The nonRepudiation bit is asserted when the subject public key is
     used to verify digital signatures used to provide a non-
     repudiation service which protects against the signing entity
     falsely denying some action, excluding certificate or CRL signing."

Here, we may agree that the word 'falsely' in "falsely denying" either means intent
or logic negation:

i. If it is logic negation than the service produces no information because the
denial was already known to be false before the "non-repudiation" service would
protect the r-p against it (and, btw, who verified it to be false before?).  Thus, the
"logic negation" use would need an omniscient and impartial overseer.  And,
following this thinking, if the denial were not false but truthful to that overseer
then it would be accepted as a valid repudiation -- which also shows that the system
does not provide for "non-repudiation" but for "rebuttable pressumption".

ii. If it is intent then the service does not apply to a protocol that only deals
with applications, not users.

Now, compare with the definition [HAC]:

where there is no need for anyone to be a "tribunal over denials" before the service
is applied (because the r-p itself is the one that defines whether the act it needs to
rely upon is repudiable or not), nor there is any need to deal with the 'intent'
interpretation (not even the r-p needs to deal with it!).  This definition seems thus to be
precise, clear and verifier-centric (btw, what non-repudiation is all about).  And,
according to this definition, denials are always prevented when acts conform to the
system --  whether the acts are truthful or false, whether there was intent or not.
This is "non-repudiation" or "non-rebuttable pressumption".  The same when a
bank clears a check that has a signature that cannot be distinguished from yours
as seen in the bank's file and there was no previous instruction by you to either cancel
that check or the signature in the file.

Thus, when we define non-repudiation as preventing the denial of previous acts,
we are precisely stating that the denial of a previous act would become a falsity in
the system -- irrebuttable-- irrespective of the details or even intent of that act.

But, why can't we say the same the other way around?  Bet we can, but as oftentimes
happen, somethings get more complicated in positive logic:

non-repudiation: corroborating the complement of the denial of previous
                               commitments or actions.

So, I prefer the form used by Menezes and I see no need to make it more complicated.

But, the questions remain -- if the "NR bit" in PKIX is thus not a "non-repudiation"
thingy, then should we rename the PKIX NR thingy or should we change its definition?
And, what name/function should it have, and whether we should at all define bits that
have repudiable definitions  :-)

Cheers,

Ed Gerck