Subject: MOTION ON NR

From: Ed Gerck <[email-masked]>
Date: Sat, 20 Nov 1999 09:55:00 -0800

All:

Looking at all NR suggestions here, it seems that above all 
we must not introduce a judgement of value (the word "falsely" 
in "falsely denies")which does NOT exist in non-repudiation 
proofs and which opens a can of worms for both engineers (we 
can't measure it) and lawyers (they can't prove it).  Worse, we 
need to recognize that the word "falsely" is entirely lame in this 
context, both for engineers and for lawyers.

So, instead of having a definition which anyone (engineers and lawyers)
could apply *and build upon*, we are faced in the current PKIX wording with
a jury decision carved in stone in a protocol.  This is what this discussion
oftentimes miss -- we should impose the *least* burden of compliance.

And, the least burden of compliance comes from recognizing that the call
whether the denial was falsely or truthfully made is NOT ours.  What we
*can* do is provide a protocol NR service *exactly* as predicated in X.509
(which does NOT include authentication, as I analyzed on 18 Nov 1999),
and which protects against REPLAY and REPUDIATION. Both terms are
well-defined in X.509 Appendix B.1 as:

 Replay -- The recording and subsequent replay of a communication
 at some later date.

 Repudiation -- The denial by a user of having participated in part or
 all of a communication.

This is IT, folks.  Simple, doable, in our turf. Let's just follow X.509 and lint
its inconsistencies for PKIX -- according to the term REPUDIATION
as *already* defined in X.509. Two definitions of X.509 need IMO to
be linted in this regard, because they are in conflict with one another
and with the  corpus of X.509 -- as I analyzed on 18 Nov 1999, here.
The definitions to be linted are:

1. nonRepudiation:  for verifying digital signatures used in providing a
 nonrepudiation service which protects against the signing entity falsely
 denying some action

which should become (eliminating the circular reference to
"nonrepudiation" itself and the lame reference to "falsely"):

1'. nonRepudiation:  for verifying digital signatures used in providing a
 service which protects against the signing entity  denying some action.

and,

2. Non-repudiation -- This service provides proof of the integrity and origin
 of data -- both in an unforgeable relationship -- which can be verifed by any
 third party at any time.

which is conflicting with the first, wrong (see why in my mail of 18 Nov 1999)
and should be simply replaced with 1' (of course, one should NEVER define
the same thing in two different ways in the same document).

For lawyer remarks on non-repudiation and the distinction we ourselves
often miss here between technical and legal assessments, please see [1].

I call attention to the fact that the remarks *include* the use of the word
"falsely" from the viewpoint of the risk-bearer (who does not want the
signer to falsely deny an act) , but *exclude* that same word from
the viewpoint of proof  (where it is irrelevant whether the denial was
false or truthful -- whether the signer actually made the signature or not,
whether the signer actually intended to make the signature or not, etc.).
I believe this explains the dilemma facing those (including myself) that
see the unfairness of setting up a system that can disallow truthful
denials, by recognizing that "truth" is a matter of reference -- if the
customer wants his check to be cashed without the bank calling (and,
charging) him for every check to be paid, then the client must accept
that the bank needs to independently verify whether the signature is
correct or not, truthful or false. This is the truth that the client accepts,
and accepts it because she profits from it.

Of relevance is only if the technical assesment can be used (and, herein
lies the slippery slope for this PKIX WG, in our social liability and ethic
as engineers) to support a legal assessment holding that the apparent
maker of the signature is bound by it  -- *whether she made it or not*.

This opinion confirms that non-repudiation is that which can prevent
even truthful denials, not only false denials.  So, non-repudiation
has to do, logically speaking, only with preventing denials (since both
complementary cases of truthful and false are included and decided
elsewhere).

Thus, let's not try to include jury, judge and executioner in our protocols.
Therefore, to be concrete I propose the following *minimum* changes:

----------------
 MOTION ON NR

 That definition 1'  be accepted, that definition 2 be replaced with 1' --
 all in their equivalent places in PKIX from X.509. The X.509 definition
 of repudiation stays unchanged.

 The actual specification how the NR services are provided need not
 concern PKIX, as they are bound to be different for each realm
 of application (common law, civil law, military, government, private
 sector agreements, intra-company, etc.), CPS, etc. Thus, the
 specification of NR services is to be considered outside the scope
 of PKIX.

 Tom Gidin's proposed RFC provides one example of how NR services
 can be implemented. Implementors are free to devise their own
 examples, if  needed.

 The current PKIX specification that keyUsage bits are independent
 should NOT be changed, and wording to the contrary in PKIX should
 NOT be used for compliance testing (they are merely examples of usage).
----------

Cheers,

Ed Gerck

[1] Remarks received in private from Nicholas Bohm, a lawyer that used
to work for banks in the City of London, Cc'd above.

1       It is often (although not invariably) a desirable objective of a system
to provide a non-repudiation service, either to prevent a signatory from
falsely repudiating a genuine signature or to prevent the recipient of a
message from falsely denying its receipt.  Whether a particular system
provides such a service, and the degree of its reliability, are matters for
technical assessment.

2       If a system is believed to provide a reliable non-repudiation service,
and is used in circumstances where legal consequences may follow the
signing or receipt of a message, the contractual terms which establish the
legal framework for the operation of the system may provide that what the
system recognises as a valid signature shall bind the apparent maker,
whether she made the signature in fact or not; or that where the system
records a message as having been received, the apparent recipient shall be
treated as having received it, whether he received it in fact or not.  Such
terms may be described as providing for the non-repudiation of signatures
or receipt of messages.

3       A technical assessment may prove that it is highly probable that a
signature was made by its apparent maker.  A legal assessment may hold that
the apparent maker of a signature is bound by it whether she made it or
not.  These two conclusions seem similar, but operate in different realms
of thought.  Debate about non-repudiation sometimes overlooks the
distinction, to the evident frustration of the lawyers and engineers whose
arguments pass through one another like angry ghosts.

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Nov 1999 10:30:38 -0500

I cannot support this direction.  You suggest:

The signer can always deny taking some action.  The point is having 
evidence to refute the claim if it is false.

Russ

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 22 Nov 1999 10:55:14 -0800

>evidence to refute the claim if it is false.

Of course.  I think we must all agree that we use the phrase "prevent a denial"
to mean that we "prevent someone from prevailing in a denial".  If they deny
but lose, that's ok.

I would accept "prevailing in a denial of some action" just to eliminate one
more point of argument (yes, insert laughter here.)

___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: Irene Gassko <[email-masked]>
Date: Mon, 22 Nov 1999 14:14:47 -0500

"Denying some action" sounds somewhat vague to me :-). There are plenty of
actions not related to that signature which you can deny to your heart's
content.
Shouldn't it be something like " denying an action authenticated by that
signature."?

Irene

>email: [email-masked]                                   LLLLLLLL

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 22 Nov 1999 11:33:30 -0800

Irene,

Yes, absolutely.  Put both together and we get:

    "successfully denying action authenticated by that signature"

We must be careful, however, to avoid one of Murphy's Correlates:

    "By making things absolutely clear, people will become confused."

:)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Nov 1999 11:42:58 -0800

Russ Housley wrote:

> The signer can always deny taking some action.

Russ:

This is a basic right that the signer has.  It is not a function of the protocol
to be a tribunal over the signer and decide *beforehand* whether the denial
is truthful or false -- this is unworkable as we may see in several examples of
temporal logic.  Indeed, the signer may always *later on* deny  taking some
action and the risk-bearer (aka, the relying-party) may decide (or not) that is
worthwhile and possible to protect against such denials *beforehand*.

> The point is having evidence to refute the claim if it is false.

Exactly the point -- but even truthful denials may not be acceptable.
I believe this goes to the heart of the dilemma facing those (including
myself) that see the unfairness of setting up a system that can disallow
truthful denials, by recognizing that "truth" is a matter of reference -- if the
customer wants his check to be cashed without the bank calling (and,
charging) him for every check to be paid, then the client must accept
that the bank needs to independently verify whether the signature is
correct or not, truthful or false. This is the truth that the client accepts,
and accepts it because she profits from it.

In other words, if the signer wants (and profits) from open-loop
acceptance of her orders then the signer must cope with closed-loop
errors which might occur within a risk boundary.  If this is unaceptable
for any risk whatsoever, then the signer should NOT give the risk-bearer
the impossible task of accepting an order that looks like a duck,
quacks like a duck but is not a duck -- i.e., the risk-bearer would need
to reject all orders until proven by the signer in person, in order to avoid
uncovered losses.  E-commerce and banking could not work like this,
of course.

Non-repudiation is a tool that apportions risk -- where the signer risks
paying for a transaction that she claims she did not sign for but which the
risk-bearer could not distinguish from a transaction that the signer did
NOT sign  (note the subtle negative logic here), while the risk-bearer risks
accepting a transaction which the signer can later on prove in a balance
of probabilities that it could not have been made by the signer.  In
either case, whether the signer's claim is truthful or false is irrelevant.
What is relevant is what the risk-berar is able to decide *incomunicado*
from the signer whether that transaction is likely to be repudiated or not
-- which is *independent* from its authentication in integrity and origin.

Thus, preserving the ability of open-loop decisions in a fair system is what
IMO non-repudiation is all about -- and, why it is needed especially on
the Internet where the loop is *always* open (the Internet viewed as
network of networks, where no one can control both ends of a
communication process, nor the route in-between).

Finally, non-repudiation is a tool to build trust when trust is viewed
as qualified reliance on received information.   The risk-bearer needs
to rely on the received information in order to make decisions.  This
trust can be earned protocol-wise for each transaction and can also be
cumulative, not just given away as an open-ended authorization
equally valid for all transactions.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Nov 1999 11:51:02 -0800

> to mean that we "prevent someone from prevailing in a denial".  If they deny

Yes.

> more point of argument (yes, insert laughter here.)

No protocol can guarantee that the NR service will  be"prevailng in a denial of
some action".  Perhaps some other term can be found to make it clearer?

Cheers,

Ed Gerck

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Nov 1999 14:44:54 -0500

Tony:

How is that any better than "... a service which protects against the 
signing entity falsely denying some action."

Russ

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Nov 1999 14:02:09 -0800

Russ:

Because wheter the denial is false or truthful is irrelevant to the protocol.
The signer may be 100% truthful  in that he did not sign and yet the NR
system in place, which the signer accepted beforehand (in order for
example to be able to have his checks accepted without paying/delaying
for a live confirmation for each check), will still provide the risk-bearer
with a tool to prevent the denial of a signature that did not look like
a signature that the signer did NOT make (negative logic is necessary
here).

However, writing

1'a. nonRepudiation:  for verifying digital signatures used in
providing a   service which protects against the signing entity
prevailing when denying some action.

seems to me to be an "explanation mode" definition, which explanation
could be provided in a short comment.  The same applies to

1'b. nonRepudiation:  for verifying digital signatures used in
providing a  service which protects against the signing entity
prevailing when denying actions authenticated by that signature.

since the "actions" are NR-specific actions that  may (or,
may not) directly depend on the signature. This can be likewise
explained in a short comment, where one must carefully restrict it to
NR service specified actions -- e.g., possibly NOT including:

-- actions based on semantic content of the signed message itself;
-- all actions that can be possibly derived from that signature;
-- the signature itself  (desired may be only non-repudiation of a
     time stamp, for example),
-- etc.

or, possibly including ANY or even ALL the above.

That is why IMO the definition

1'. nonRepudiation:  for verifying digital signatures used in
providing a  service which protects against the signing entity
denying some action.

could be useful, since its eventually dubious aspects are few
and they can be explained by *short* expanding notes from the
root concept of "some actions", to wit:

i. The words "some action" mean specific actions protected by
the service, and may include any aspect of a digital signature
including its signed content.

ii. The words "the signing entity denying some action"  mean
the signing entity denying the action itself after the action.

iii. The signing entity may always deny some action at any time.

iv. The words "protects against the signing entity denying some
action" mean that the service intends to prevent the signing
entity from prevailing in a denial of some action, as qualified in
(i) and (ii), to some degree. The signing entity must however
always be sucessful in denying some action before the action.

v. The words "verifying digital signatures used in providing
a  service" mean that a service boundary is defined when
verifying  digital signatures, which service boundary may
nonetheless vary from service to service.  The service
boundary is a conceptual (though it may also be physical)
limit.  It is irrelevant to the service whether the denial of some
action is false or truthful outside the service boundary.

Comments?

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 22 Nov 1999 14:08:52 -0800

>signing entity falsely denying some action."

Russ,

Not much better!  Only helps to recognize that many moons ago, some of
the NR threads asked the question "How can NR prevent me from denying...".
Of course, nothing can prevent you from "issuing a denial".  Hence the
wording above MUST interpret "protects against ... denying" to mean
"protects against ... prevailing in a denial".  It does not alter
the (untenably vague) meaning in the overall definition.

Seriously, why not substitute "certificate subject" for "signing entity"?
The so-called "signing entity" is nowhere an element of the certificate.

And what is this "some action".  Why would it hurt to be a bit more
precise.  Clearly, "some action" must be something authorized by the
signature in question, as Irene Gassko wrote.  Perhaps this is just
another one of the "its understood" things that too many of us don't
seem to understand.

Indeed, as I wrote several months ago, as a "signer", I might want NR
myself:  Perhaps I am signing my patent submission.  If anyone later
tries to deny (falsely, if you must) that I signed or submitted that
patent, it would be a rival developer, not me.  So it seems that the
current definition is biased in this regard.  It assumes only the
(purported) signer might be restrained from "falsely denying some action".

Just as surely, this NR service would

   "protect the signer in truely affirming some action".

Why is the current definition skewed in this regard.  The way it is
worded, it is assumed that the only wronged party can be the RP.

Now a difference of opinion exists between Ed Gerck, who maintains that
NR should serve as a "trump card", that cares not whether the denial
is true or false (sort of like the deductible you agree to pay anyway)
and those who expect NR to simply (and neutrally) allow a trusted
third party to hold/adjudicate over evidence.)  If we take the former
position (NR hedges both true and false denials), then indeed the
definition has the "right" to be skewed.  But if we intend NR to
support the more neutral "independent evidentiary" service, then
it should not be so skewed.
 
___tony___

>> providing a

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 22 Nov 1999 14:59:33 -0800

All,

Would it not be more "up front" to refer to the "signing entity"
in the NR definition as the "certificate subject"?

Granted, in these circles it may seem to be another one of those
"understood" things, but to common folk it might appear a bit
disengenuous.

Suppose I am about to execute an electronic contract with you,
and I'm all ready to hit the "sign with NR here" button.  But I
have second thoughts, and get up to brew another cup of coffee.
In my absense, a neighbor walks in, and out of mischief or
misguided helpfulness, clicks the button for me.

Who is the "signing entity"?

(Yes, I may well be the liable party, and "effectively" the
signing entity.  But many would reasonable hold that the person
who "effected the signature" was the neighbor.  So... )

I go to court (or am taken there upon refusal to honor the
contract) and I subpoena my (now uncooperative) neighbor as a
hostile witness, claiming that they perpetrated a fraud by
signing with my signature key.  The neighbor falsely denies it.

The NR definition says "protects against the signing entity
falsely denying...".  Now in fact, my neighbor is the signing
entity, and is falsely denying!  But NR is not interested!

As the relying party, you don't care to be protected from my
neighbor's false denials (especially is they have no assets;)
You intend to hold ME responsible (as I may well be through
negligence) and NR only serves you in this regard.  Why ME?
Not because I am the "signing entity" in the commonly used
sense, but because I am the certified key holder.

So why not replace "signing entity" with "certificate subject"
and eliminate one more point of semantic indirection and
confusion?  Unless you are prepared to be able to distinguish
the two (especially via the NR service) I see no reason to
obscure this issue.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Nov 1999 15:49:21 -0800

> The so-called "signing entity" is nowhere an element of the certificate.

Good point. And X.509 also uses "signer" for the same purpose. So, we
could indeed lint these occurrences and unify the references.

> precise.

No, it would not hurt at all. See my previous msg where I suggest that
all necessary comments/context be added as short notes after the definition.
I already list five notes -- which would make the definition itself cumbersome
if smply added to it.  In trying to making things clear we need of course to
include a chain of references, which cannot become so long that the
definition may actually become an essay by itself ;-) ... that is, if those
references are included in the definition itself.

> it should not be so skewed.

Yes. The "skew factor" can however be reduced or increased by chosing
a boundary for the NR service (see my previous posting).  As the NR
service boundary increases, more variables and subsystems are included,
but processing time, cost and inconsistencies also increase (a  system of
some complexity cannot be both consistent and complete, as a general
property also valid here). Eventually, a compromise must be reached for
the NR service boundary -- whatever it is, it cannot be infinite. Then, some
variables must be left outside and it is irrevelant to *that* NR system
whether those variables are truthful or false.  Another nesting NR system
may, however, use the result of the first NR system and apply other variables
that were missing from the first NR result, arriving at a second NR result,
which may differ from the first and which may (or not) superseed the first
NR result, and so on for a series of nesting NR systems. This can happen
both in the technical as well as in the legal domain, or between both -- as
when a higher court (a third NR system) asks for a new technical expert to
be considered by a lower court, effectively increasing the boundaries of the
variables considered in the first NR result -- which may or may not alter the
result.

So, what we are dealing with here is a NR service which can be defined
according to need while, at the same time, remaining neutral to anything
that lies *outside* the service.  The alternative would be to prejudge that
which lies outside the system -- even before the result from the system is
ever announced. A logic design flaw which can be circumvented by
considered nested NR systems as commented above. In terms of trust,
the nested NR systems correspond to a trusted chain of events built
from the one trust-point backwards -- for example, in a decision tree.

Cheers,

Ed Gerck

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Nov 1999 09:25:47 -0500

We just disagree....

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Nov 1999 09:27:30 -0500

I do not mind if we substitute "certificate subject" for "signing entity".

Russ

---

From: Ed Gerck <[email-masked]>
Date: Tue, 23 Nov 1999 07:34:08 -0800

Russ:

OK and, more than respect your opinion,
I think you are right that in some cases using
the qualifier "falsely" before "denying" may
make more sense.

And, that is why I suggest we abolish it
(along with some linting) because there
are cases where IMO it does not apply --
so, deleting "falsely" serves all cases
since it logically negates none.

For example, a specific NR service can
introduce the need to somehow verify
if the denial  is "false" before the
denial itself is technically verified --
thus, reintroducing the "falsely"
requirement.   Another NR service
might require that first the denial
itself be technically verified, before
somehow verifying if the denial seems
to be falsely or truthfully claimed.

This seems to me to be a quite even-handed
approach. Would this seem to be neutral to
you also?

Cheers,

Ed Gerck