[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>> From: Ed Gerck <egerck@nma.com>
>>
>> Second, 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.

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]:

"non-repudiation: preventing the denial of previous commitments or actions"

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