Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be, or NR To Be ...

From: "Bob Blakley" <[email-masked]>
Date: Wed, 18 Aug 1999 10:24:37 -0500

Ed,

--bob

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

>Reading your paragraph above -- when you talk about NR -- it is clear that
>you think:
>
>1. Only the use of NR will allow you to prove something to a judge

No; I absolutely do NOT think this.  In fact, just the opposite.  NR may NOT
allow you to prove something to a judge.  It's just evidence, and like all
evidence has some probative value relative to the charge, the rules of
evidence, the mood of the judge, etc...

>2.  Only the use of NR will be able to make the user accountable

Again, absolutely not.  Accountability is embedded in some kind of regime.
In what I call authoritarian regimes, where a single source of authority is
judge and jury and that source trusts the sysop, an audit log is just fine.
In other regimes, NR is fine.  In many regimes, NEITHER of these is yet
considered worthwhile evidence.

>3. Only the use of NR will provide legal evidence of user actions

Again, I don't think this at all.  Only legal evidence is legal evidence.
 NR -- or
other kinds of technical artifacts -- may or may not be legal evidence,
depending
on the legal system and rules of evidence in use.

>So, these topics can be seen as "definition" of NR -- and you are not alone
>because this is essentially what the DMS and ISO concepts of NR are all
>about.  Well, these topics are all false in regard to non-repudiation, so
that
>NR <> non-repudiation.

This *isn't* what the ISO definition of "NR" is!  The ISO definition is a
technical
definition of a service which produces evidence tokens associated with
certain kinds of requests.  Whether what this service provides is admissible
in any court whatsoever, or what its probative value is, is not addressed AT
ALL
in the ISO specs.

>But, this is not the main problem. The main problem is that you did not even
>talk about non-repudiation!  In your entire text, the notion of
non-repudiation
>did not appear even once.
>
>Contrary to what Steve Kent believes, there is a very clear idea in business
>and banking about what non-repudiation is.  What those sectors do not know
>is how to represent that in a reasonable fashion in security protocols --
and,
>thank God they don't ;-)  So, how about we trying to find out how to do it
>before they do it?
>
>Oftentimes, a word is used just to satisfy a market need -- and, surely, we
can
>read press-releases of security companies that currently deliver products
with
>"non-repudiation" and at least one company even went as far as declaring that
>it delivered products that offered "true non-repudiation".  Isn't this the
same as
>those "FREE" offers we read all the time? We all know it ain't FREE, so it
>simply does not work after a while.  But, is this what we want?
>
>To be fair, the motivation for the NR definition is a laudable one (contrary
>to many of those FREE offers).  Indeed, this definition of NR reflects a
concern
>to improve security and it also recognizes that an element of proof is needed
.
>
>Where it fails is that it follows a common non-lawyer approach to solve a
>legal issue -- non-lawyers believe that if they explain something "really
well"
>and provide "strong proof" then they will have a fat chance to win in court.
>It is all a drive forward, a positive assertion -- more files, more logs,
more
>crypto keys, more digital signatures.  So, NR as you use it (and you are not
>alone) is simply proof of authentication.  But, never non-repudiation.

No, no, no and no.  None of this has anything whatsoever to do with what I
think of as NR, and I'm not laboring under even a single one of the
misapprehensions
you describe.  I understand rules of evidence and admissibility quite well, in
fact,
and I know a lot about the circumstances under which logs, files, keys, and
signatures are admissible, relevant, and probative.

Furthermore, what I describe has nothing whatsoever to do with authentication.

>Why? Because non-repudiation needs to be deniable a priori in order to be
>legally valid -- yes, and please do not change my word "deny" to "refuse" ;-)
>Because non-repudiation is a "two-prong test" [*] that allows a relying-party
to
>thwart a truthful denial (made a posteriori) with a legal affirmation (made a
>priori).  Because if it does not allow all this, then it is not
non-repudiation.

What you describe is called (in the US anyway) presumption, not
non-repudiation.
Actions can create a presumption, and the presumption may or may not be
rebuttable by certain arguments or evidences.  To translate into terms I've
heard
used, what you're saying is that

    business non-repudiation is the creation of a non-rebuttable presumption,
binding upon
    an initiating party, which a relying party can use to hold the intitiating
party to some
    stated liability even if the intiating party truthfully denies having been
the actual
    initiator of the action in question.

Such a thing is useful in some contexts but is certainly not the only, or even
perhaps the
preferred, definition of non-repudiation.  It's quite important to note that
the legal system
isn't going to allow automated processes to create these sorts of
presumptions - actions
of humans are going to be what creates presumptions like these, and a
non-repudiation
service's function in a situation like this is probably going to be (exactly
as I've stated
several times already) to record evidence of the action which created the
presumption
in a way which makes it difficult to forge or alter the evidence.

>And please note what I say above. That even the strongest of proofs
>(more files, more logs, more keys, more signatures, better timestamps,
>better whatever you want) made afterwards to a judge is powerless
>against a legal affirmation made a priori -- when non-repudiation is
>either correctly applied or denied.   Thus, the non-lawyer approach
>must fail in either case.

This is the case only if the presumption created is non-rebuttable.  Most
aren't.
In the US legal system, which allows trial by jury even in civil cases in many
instances, it's NEVER the case that proofs are powerless, because of
jury nullification (the ability of the jury to render any verdict it chooses
even if
the evidence and the law indicate that a different verdict should be reached).

Where we agree is that the non-lawyer approach must fail.

>That is why a change of heart is needed.  What DMC, PKIX and ISO
>have been calling "non-repudiation" simply is not non-repudiation -- is
>proof of authentication.

Wrong on both counts, in my opinion.

>And, maybe this is one way out of this corner were are all painted in.   We
>may change the current NR bit name to "PA bit" -- proofOfAuthentication
>bit. In a rather humorous rendering:
>
>- We hereby declare that when the proofOfAuthentication bit is asserted in a
>  certificate, any  message signed with the certificate can be used as legal
>  proof against us, but not otherwise.

Except that the name is completely wrong, this is essentially what's being
advocated on the list, I believe.

>But, I suggest to indeed add a non-repudiation bit -- exactly because
>non-repudiation is NOT the same as authentication, or strong authentication,
>or proof of authentication.  Non-repudiation and authentication are
>complement operations (technically speaking, reference upon request). As
>I wrote earlier, my suggestion to define non-repudiation in PKIX is that
>the text would negate any semantics to the non-repudiation bit beyond its own
>syntactic expression as a boolean bit, while defining non-repudiation as
>a qualified pointer (i.e., avoiding the dangling clause problem):
>
>1'. Non-repudiation is defined in the CPS and its usage is asserted by
setting the
>nonRepudiation bit.
>
>I also suggest to follow Tony's comment and define all other usage bits that
are
>not taken, calling them by generic names (say, in a humorous tone, Green,
Red,
>Blue):
>
>- The Green service is defined in the CPS and its usage is asserted by
setting the
>  green bit.
>
>etc.
>
>Thus, what some sectors of the security community have felt a need to express
>(and, with which need I agree), will be well represented by the PA bit. This
>includes some needs previously expressed by Dave Kemp as the "XYZ" bit.
>Thus,  marketing materials can say that a product offers "true proof of
>authentication" without a  second thought (if, indeed, it does, of course).
>
>Likewise, what some sectors of the business community have felt a need to use
>and apply as non-repudiation will be well represented by the non-repudiation
bit
>in support of such (future?) uses.
>
>And, other special services will be available as flagged by the R,G,B bits.
>
>Comments?
>
>Cheers,
>
>Ed Gerck
>
>[*] defined here in some of my messages.
>
>

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 18 Aug 1999 11:11:07 -0700

Bob and Ed,

Well,  For all of the apparent disagreement, it does seem that a kind of
common ground has been reached.  Namely, a distinction between several
kinds of so-called "non-repudiation" assertion:

1.  NR = declaration of non-rebuttable presumption

2.  "NR" (PA) = proof of authenticity

3.  NR = assent to legal context

Unfortunately, the terms may vary in meaning according to context and
perhaps political system.  So it might be best to try and characterize,
for each of these three assertions (at least) according to several
salient features.  For instance, does the signer control "x" on a
per-key or per-signature basis? (I'm certain Ed can list others:)

It is somewhat a waste of time to try and define exactly "what is proof",
since as Bob points out, it is essentially determined by trial outcome.

More to the point, it needs to be determined for which, if any, of these
meanings/usages a single cert-bit is a sufficient indicator (cert CPS
notwithstanding.)  In other words, when are we trying to accomplish
with a cert-bit, that which really requires a constellation of lesser
transactions to establish?  In the same way that traditional "contract
signature" involves the ceremony of multi-party presence/witness,
perhaps an "I meant to do this" protocol, involving multiple parties,
needs to be invoked as a component of digital contract signature.

Comments?

___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: Wed, 18 Aug 1999 13:11:17 -0700

Bob Blakley wrote:

> Ed Gerck wrote:

This is a simple confusion. I did not write that the judge will *accept* your
proof.  I wrote that I believe you think that "Only the use of NR will allow
you to prove something to a judge" and this is what you say when you use
the word "evidence" -- above and in your texts. All evidence is presented
with the intent to prove something--  and you present it so that it allows (in
the sense of enablement) you to prove somenthing to the court, the judge,
etc.  In law, no proof is ipso facto and a proof can always be repudiated
(and this is another confusion in terminology of "repudiating proofs" vs.
"non-repudiation of a proof" -- see footnote [1]).

In fact, the use of NR may not allow you to prove something to a judge even
though you present "proof", so I agree with what you say above -- and I
already did agree with this when I wrote my summary point (1),  that is also
why I wrote WILL  and not MUST in my sentence: "Only the use of NR
will allow you to prove  something to a judge".  Please note also that I wrote
"the use of NR" because NR is not used alone in your model and I recognize
that -- there is something that uses NR.

Thus, I believe my sentence captured the essence of what you have been saying
here in regard to "proofs" and the use of NR, as I can also read in your other
emails, for example, as you wrote:

} In a model in which login is subject to NR evidence generation ... you could
} get into lots of situations in which the user's login implies consent or assumes
} liability.

where you employ "NR evidence generation" as a conditional to derive an user's
implied consent or liability -- thus, using NR to derive proofs with potential legal
consequences (if accepted by a court). Or, in the other text you wrote:

} 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.

Now, please do note that I do NOT disagree with anything that you wrote in the above
quotes -- I am just showing that they are included in my summary point (1) of
"your" definition of NR and this is fair because this is what you declared NR to be.

> considered worthwhile evidence.

You yourself admit above that accountability varies according to the regime
but this does not invalidade my summary of your argument line -- in fact,
strengthens it because I can subsumm all your NR arguments for NR enabling
user accountability under my item (2) above; where "accountable" will be modal
according to each regime.

Thus, when I say that you believe that "Only the use of NR will be able to
make the user accountable", I am saying that in whatever regime the user is
held accountable ("authoritarian", legal, etc.)  you state that NR is needed
in order to provide evidences deemed adequate for each case.

Again, please do note that I do NOT disagree with anything that you wrote in
your quote -- I am just showing that they are included in my summary point (2) of
"your" definition of NR.

>  NR -- or other kinds of technical artifacts -- may or may not be legal
> evidence, depending on the legal system and rules of evidence in use.

This is a simple confusion. The term "legal evidence" is a technical term in
law -- not absolute, but relative to many things. For example, X may be
legal evidence to the defense but the judge may have it removed because it
was submitted after the deadline, or X may be legal evidence to the prosecutor
but the judge may not accept it because the defense successfully claims
conflict of interest, or a witness may provide legal evidence but be descredited
in court, or by a truthful denial that the court accepts, etc.

Your claim, however, is that one needs to use NR (and that is why you defend its
need) in order to have the ability to produce legal evidence of user actions. I can
read this in one of your other emails:

} Nevertheless, none of these things has fundamentally to do with the technical
} aspects of a non-repudation service.  Such a service ought simply to produce
} evidence of a transaction, and ought to have the property that it's easy to
} explain to an adjudicator what must be done in order to successfully forge
} such evidence.  The adjudicator can then decide for himself the probative value
} of the evidence, and whether it's germane to the accusations being made.

And, in your other phrase when you *deny* ("unlikely to be able") the capability to
"prove to a judge" when normal (i.e., not non-repudiable login) is used:

} Why would you want "nonrepudiable login"?  Normally no liability is associated
} with logging in -- it's what you do afterward that creates the liability.  The
} system owner has no interest in holding you accountable for logging  in, and is
} unlikely to be able to prove to a judge that you didn't walk away in the middle of a
} session.

Again, please do note that I do NOT disagree with anything that you wrote in the above
quotes -- I am just showing that they are included in my summary point (3) of
"your" definition of NR.

> that NR <> non-repudiation.
>
> technical definition of a service which produces evidence tokens associated with
> ALL in the ISO specs.

And, yet the ISO specs do (though you don't, and I granted you that
improvement)-- when they mention "irrefutable evidence" (a well-intentioned
fiction of an absolute probative value).  You clearly stayed away from that slippery
slope of evaluating a proof -- which PKIX and X.509 have however followed
when they mention "falsely denying" and thus included intent and proof
evaluation in a protocol over the wire.

Note also that I agree 100% with all your explanations on NR -- I see nothing that
I would change in them either!

So, what are discussing about?

Because IMO your definition of NR (as well as ISO's) is NOT what one
considers to be non-repudiation (and this is the point around which we spin
here) [2].  So, I disagree not with your definition of NR but when you (following
ISO precedent, however) equate this technical concept of NR with the legal and
business concept of non-repudiation.

In fact, I believe your definition of NR is germane for a defintion of "proof
of authnetication".  And you and others, as well as myself, have several times
agreed here that one must not always grant "proof of authentication" rights to
the verifier -- or, sometimes, that is simply not possible.  Thus, it is useful to
have this feature ON/OFF in a certificate:

- do you want a certificate that will be used in all transactions for which you agree
beforehand that proof of authentication can be collected and eventually used to
provide evidences of such authentication?

And, exactly because this authorization is granted *beforehand* and such is
strongly (crypto sense) affirmed in the certificate itsefl by setting a PA
(proofOfAuthentication) bit -- that it is legally admissable as evidence.

Otherwise, one might even argue (and, declare with full legal support
worldwide by  Intellectual Property law) that anything signed with a
private-key and the signature itself are documents (a string of bytes) that are
copyrighted at the moment they are made tangible (just like this email is)
and thus cannot be used by a third-party unless the copyright owner so
authorizes, and for the authorized purposes.  And, if the authentication
spec or the CPS says that nothing signed with that PA bit OFF can be
used as evidence in any way -- so it is effectively denied.

Now, non-repudiation is a different subject altogether [1].
Non-repudiation is that which allows a truthful denial to be
thwarted by a legal affirmation [2], hence the extreme care
this matter must be handled.

But, this NR discussion is far simpler and can be cleared IMO by
using a denotationally improved name for it: proof of authentication
-- the PA bit. This is what you  describe and this is what PKIX can
handle "out of the box" and this is also what ISO tries to describe
(but irrefutably fails by calling for "irrefutable evidences").  However,
since IMO the PA bit is useful then it is also useful to make it clear
-- what you mean by "NR" is actually proof of authentication,
so ... name it so.

BTW, that is why I said I was sorry to use your text as an example of
what non-repudiation is not -- because I think that your text is useful
and clear on what PA is.

Cheers,

Ed Gerck

[1] 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.

[2] The evaluation whether an act can be truthfully denied is
irrelevant if that act falls under non-repudiation [1] -- the only
thing that matters is that the act *reached* the relying-party, not
who did it or how it was done.  For example, when credit card
holders agree to non-repudiation of a US$ 50.00 charge in the
event of card fraud.  And this is oftentimes acceptable even
under the legal doctrine of "mens rea" and the excuses the
law admit, which reflect the fundamental moral principle that a
person is not to be blamed for what he has done if he could not
help doing it, because the law concentrates on cognitive elements
in responsibility, rather than on the defects of volition or will -- it
is presumed that if a man knows what he is doing then he has the
capacity to adjust his behaviour to the contractual requirements.