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 16:04:36 -0500

Ed,

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

The most important word I was objecting to in your statement
was neither "evidence" nor "proof" -- it's "only".  Lots of things other than
NR evidence allow you to prove things to a judge.

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

Again, this isn't quite right.  One *may* use NR to produce legally admissible
evidence, but one does not *need* to use NR -- there are other ways to
produce admissible evidence.

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

But I disagree that what it is is proof of authentication.  Let me give an
example.  Imagine that I'm using SET to initiate a transaction with a
merchant.  SET has a mode in which my name & credit card number
are not divulged to the merchant -- all the merchant gets is a NR token
demonstrating to the cardholder's bank (the issuer) that it should pay
the merchant's bank (the acquirer) the sum listed in the token from the
account (which the issuer is able to extract from the token).

In this scenario, when the merchant receives the token, not only is
there no *proof* of authentication, there's no authentication, and in
fact there's not even any identification.  Yet there IS non-repudiation
evidence, and the merchant *can* use this evidence.

=========

Finally, I think restricting the definition of non-repudiation to strongly
non-rebuttable presumptions will tend to discredit the technology, since
many kinds of transactions require much weaker presumptions.  Credit-card
purchases, for example, are explicitly repudiable after the fact and liability
of the cardholder (who performs the signature act which creates the
presumption) is limited to a very small sum - $50 in the USA.  This
doesn't fall under your definition of non-repudiation, but is a purpose to
which businesses clearly want to put signature technologies coupled with
what they have come to think of as non-repudiation protection.

It's also the case in lots of countries that it's not legal under the
prevailing
commercial codes and consumer protection statutes to put consumers
into positions in which their acts create non-rebuttable presumptions
with associated liability -- this would exclude the use of what you're
defining
as non-repudiation protection in many commercially interesting applications
in many jurisdictions.

--bob

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

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 18 Aug 1999 15:03:44 -0700

>evidence, and the merchant *can* use this evidence.

(I am expert in a different SET theory;)

When you say there is no authentication/(or even identification), I believe
you must be using these terms in the limited sense "this was demonstrably
signed by Tony."  I tend to apply the terms authentication and identity
a bit more broadly, even in the PKI context.

To stick with your example:

1.  Your part in the transaction helps produce the "NR-token".  Ostensibly,
    I could not produce such a token and present it to the merchant so that
    your account would be charged.  Thus, your uniqueness must come to bear.

2.  The merchant receives and can forward this token to (your issuing) bank.
    The token, or some associated instrument, must convey the identity of
    the merchant's bank to your bank, so that it will authorize the funds
    transfer.  Again, ostensibly, this must be a tamperproof process so
    that the funds cannot be misdirected.

Suppose, in one case, the merchant forwards the SET token, but the bank
decides (somehow) that this token is forged, and refuses to make payment.
(How would it ever know, if authentication were not involved?)

OK, here the transaction would break, the merchant would not deliver the
goods to you in the first place, so no loss.  Clearly this protocol must
enforce (merchant/merchant's bank) is satisfied in order for the transaction
to complete.

Suppose it does, but you never receive the ordered merchandise.  You take
issue with the merchant, who declares they have never had any dealings
with you at all.  Where is the evidence that YOU were a party to the
transaction?

Alternately, if I were to claim to be the "you" in the transaction, and
complain that I have not received the promised goods, how might the
merchant demonstrate that it could not have been me?

Curious.

___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 15:37:28 -0700

> account (which the issuer is able to extract from the token).

There are two authentication acts going on, in the above -- not just one.
And, it works because these these two acts form a closed circuit; you
will recognize a flavor of SPKI in it.

What is called the "NR token" above is an "authentication token" that the
merchant can use to demonstrate to the cardholder's bank that it should
perform an act.  This "demonstration" is thus an authentication that
the relying-party (the cardholder's bank) must perform when the token is
received.

In this scenario, when the merchant receives the token, that token has
value exactly because it can be authenticated by the cardholder's
bank -- i.e., it can be corroborated by the cardholder's bank.

But all this would be moot if that value would be repudiated.  Here,
repudiation is avoided by an authorization chain which begins and
ends with the *same* entity -- the token is authorized and issued
by the cardholder's bank and then authenticated by the same.

Since the cardholder's bank is at the same time both the issuer and
the last relying-party, the system works based on the cardholder's
trust that no attacker can produce a token that the cardholder's
bank will mistakenly accept and the trust that no token produced
by the cardholder's bank will be rejected.  This is simplified by the
fact that since that bank is at the same the issuer and the verifier,
there is no limit on the type andd number of authentication proofs
it may require from itself -- it is, basically, a question of risk and
cost, not of denied rights or legal battles.

[paraphrazing]:
Thus, there is *proof* of authentication, there's authentication, and in
fact there's even identification -- since the issuer knows that the token
is identified as of its own making.  Yes, there IS non-repudiation
but not based on any evidence besides that authentication proof --
since here non-repudiation is based on the fact that the bank warrants
its own services to itself, believes its own files and is its own tribunal,
being also its own laws, jury and executioner ;-)

> many kinds of transactions require much weaker presumptions.

No, for one it will credit the technology for not making easily rebuttable
declarations about a "non-repudiation service" that is not at all provided
by that technology.

Second, by using the name "proof of authentication", it will allow legal
proof of authentication to be collected and supported by the technology.
How that "proof" is evaluated is a question to be decided by the arbiter
-- a court of law, a supervisor, a comittee, etc.  The "proof" may be
deemed sufficient, insufficient, denied, or illegal. The last three cases,
all possible, do not justify the use of the name non-repudiation -- but
justify the use of the name proof of authentication, because a "proof"
is simply an evidence presented for evaluation (Webster):

proof - evidence operating to determine the finding or judgment of a tribunal.

> Credit-card purchases, for example, are explicitly repudiable after the
> fact and liability of the cardholder (who performs the signature act
> which creates the presumption) is limited to a very small sum - $50
> in the USA.

This is not correct, though a common misconception. Credit-card
purchases are not repudiable for example if there is legal proof that
the goods were ordered, received and used -- for example, a
phone debit card.  They are not repudiable in the case of fraud
by the cardholder, as another example. There are many more.

> This doesn't fall under your definition of non-repudiation,

Yes, it does, for the case that does -- as I cited before: "For
example, when credit card holders agree to non-repudiation
of a US$ 50.00 charge in the event of card fraud. "

> ... in lots of countries that it's not legal under the
> prevailing commercial codes and consumer protection statutes
> to put consumers into positions in which their acts create
> non-rebuttable presumptions with associated liability -- this
> would exclude the use of what you're defining as
> non-repudiation protection in many commercially interesting
> applications in many jurisdictions.

And, in good measure if it does!  But, there are cases where it
is in the interest of the consumer to agree with a non-repudiation
clause -- but, such clause must be very clear: Non-repudiation
is that which allows a truthful denial to be thwarted by a legal
affirmation.  Possibly useful, if properly constrained.

Cheers,

Ed Gerck

---

From: "tog" <[email-masked]>
Date: Thu, 19 Aug 1999 07:48:15 -0700

Bob Ed, pardon me for doing this in the middle of this thread... but this
has gone on much too long...

>> Imagine that I'm using SET to initiate a transaction with a
> > merchant.

Yech - but OK - do it.

> > SET has a mode in which my name & credit card number

And don't forget the boatload of process overhead, so that SET costs the
operators more in "impatience" and "frustration" than it provides for in
indemnity - These are key issues in any solutions that we produce. If we are
not here for our own ego's and we are really involved in this to better the
world and make commercial use of the Internet and open Networking a reality,
then I propose that some other conceptual ideas need to get mixed into this
conversation. Most especially what it is we are trying to accomplish and
what use it has.

> And, it works because these two acts form a closed circuit; you

I like this model but lets take it a couple of steps farther and jump up to
50,000 feet where we can  get a look at what the timestamping process is
used for anyway.

In using Timestamping, we through a complex mathematical process, create
some evidentiary element to prove some assertion of an event having occured.
It may be the validity of a particular digital signature, it may also be a
digitally signed blob of data that state's why I intended to buy the house I
just did.

As an operating requirement, we claim that these event-process evidentiary
models need to be reconcilable between themselves and other systems issuing
like event-stamps. To support this requirement, we use the one thing we all
can agree on, time. And it essentially forms the cornerstone of the
interoperability in the trust model - Viola' the Timestamp!

Now lets take the next step, the need for security in the proof process..
Lets just leave it at that our justifiable paranoia makes us create security
envelopes for the component data, so we feel better about believing them and
the events they offer proof for. That given, up here at 50,000 ft, the next
query  is what do I do with them, these timestamps? and the answer is
something like "as part of the bigger-picture,  you can either use the
protocol itself to control various types of local events by issuing signals
to an interacting process, or we can use the token that is produced as the
evidentiary proof itself."

With the first model, we see perhaps an Application waiting for the signal
from the Protocol Interface as defined in the current TS Draft, or perhaps
the receipt of the token itself triggers some event or event chain. BTW,
These capabilities  will be important for building Agent's and other
technological systems that require an authorized signal model (i..e. the
receipt of a verifiable token) to trigger some pre-programmed function,
feature, or other event or event chain.

In the second case, the token is actually the proof of the event in
question, and it is likely that the token is archived, so this is really an
audit certification process model... You just grab a token and validate it
when you need to.

Now that we understand what we are going to use the timestamping for - at
50,000 feet. That it provides a mechanism that can inter-relate provable
events to each other , we can really figure out what we need here.

In my book, the token is what's important unless you want to hand policy
flags to a control process, in which case what you want to do is issue
signals based on whether the event "verifies" or not - nothing more. So in
no uncertain terms - Timestamping is an evidentiary process wherein policy
and crontrol infrastructure all add together to create the totality of the
trust and proof models. So in this case not knowing about evidentiary
process would actually be a problem? eh?

That being said, what are we really talking about here in this conversation?
Whether the protocol for this particular NR bit use model has enough
utility, and I say not as a single bit.

The issue of the basic model of services is that the TS technology currently
lets you verify a signature was valid at some point in time, and while that
is valid as a policy control model it is only a small component of proofing
for a transaction model that will stand any audit scrutiny. Remember the
word timestamping is based in creating a stamp as the outcome, not how the
printing of the stamp was done. No one cares what the press was except the
printer, we care about the validity of the stamp.

I am sorry to bring the "morning lights" to this conversation, but the
entire TS protocol is way to complex to use, and provides the users and
developers with way to much overhead in the form of granularity. What the
protocol really needs is simple and easily called services model to create
stamps and verify them, not their discrete components alone. This will
require the creation and promulgation of standard stamps too, or has
everyone realized that already...

]The current model is rooted upon the control of policy and other services
based in signals in the protocol model regarding the validity of the
signatures, but since there is no formal stamp spec, the routines fall way
short of being something like:
o-    verifyStamp(stampID),
o-    createStamp(stampComponentList),
o-    extractStampComponent(stampID,stampComponent) ,
o-    listStampComponents(stampID), etc etc

or the distributed host version:
o-    verifyStamp(stampArchiveHost, stampType, stampID).

Personally - I think that a whole bunch of the current TS draft needs to get
flushed and replaced by a section more elevated from component features into
usable services at the app layer. Otherwise, timestamping is like I said
before, better left as an application level process with a distributed
proofing access model so that it can be accessed remotely for TTP models or
as an embedded feature.

Otherwise, my feeling is that this conversation is akin to arguing whether
'the pair of pliers should have rounded or squared jaws',  and makes about
as much sense.

Todd

---

From: Ed Gerck <[email-masked]>
Date: Thu, 19 Aug 1999 09:29:57 -0700

> >> Imagine that I'm using SET to initiate a transaction with a

;-) I would second that. But reading through your thoughtful message,
I saw no relation either to SET (thanks!), or to the NR bit semantics or
to non-repudiation semantics (both, this thread's subject).  The use of
time as evidence in a transaction is fine and useful for NR, whatever
NR is, but this is the question we need to treat from 500,000 feet:
what do we mean when that bit is set? Is this meaning clear to all
and doable? Is one bit enough?  Are the useful validity modes
represented? Or, are we involuntarily misrepresenting what can be
done and confusing the public?

Thus, I welcome the increasing perception that your comments may bring
to this thread but IMO we simply can't talk about how to do it before we
know what we are doing and whether this is doable at all within the scope of
PKIX -- this would not be pragmatism or "hands on approach" but loss of
time.  As someone said, akin to building a Maginot Line fortification and
doing so on quicksand.

> utility, and I say not as a single bit.

I would dare to say we are past this point. In fact, we found several utilities
for it -- and this is what is confusing.  Which utilities are doable within PKIX,
what part we need to refer to the CPS and what part is simply a question
we will never solve? Further, which utility is *the* one we pick, based on all
these considerations? And, can we or should we pick more than one, if
possible?  Finally, what do we mean when we say NR? Is this also what
businesses understand by non-repudiation, across the world?  Or, should
we change that NR name since we all agree the NR bit is neither necessary
nor sufficient for non-repudiation?

> proofing access model so that it can be accessed remotely for TTP models or

You make IMO some valid points.

Much needs to be said about timestamping as I see it, and I have just
been holding myself in some comments on this -- not only because,
of course (IMO) we need sub-second resolution but because the whole
subject of trust pervades reliance on time.  Time is a relative measurement,
any way you see it., and thus ... where is the reference?  We are thus back
to the same question regarding certificates ... if a certificate is validated by
another and then another... where is the reference?  In either case, there is
no absolute reference -- just relative references.

True, time only moves forward and GPS can be very precise worldwide but
indeterminacy between two independent time measurements always exists
whether in the sub-day level or in the sub-microsecond level -- so, two
independent systems that use time in order to create a reference common
to both will have that indeterminacy to cope with.  Which will be,
paradoxically, equally significant in a system that has a resolution of one
day versus one that has a resolution of one microsecond.  Security
protocols will not be able to work bellow that system's indeterminacy
(whether day or microsecond) and this is where they will be attacked,
no doubt. Using systems in series, an attacker could also create race
conditions that would very much magnify the relevance of that
indeterminacy. Super-attackers could use their superior connectivity
or computing power to create imbalance. Denial of service could create
isalnds of time. MITM attacks could create arbitrary time.

> 'the pair of pliers should have rounded or squared jaws',  and makes about

As an electronic engineer, I tell you it makes much sense. Square-jaw pliers
may not produce the needed curvature when used as a handtool to bend a
component's leads. Also, round-jaw pliers may create too much pressure
when crimpring a wire in a connector.  But, the discussion on this thread
was not even at this level of tool detail (which you seem to bring in with time,
though). Rather, some are calling those tools "screwdivers", others are calling
them "hammers", others still are calling them "wrenches" and we are having
a great time because no one really knows what those tools are to each other
-- and this is what we are trying to find out in an intersubjective agreement.
Though it may look like an objective disagreement ;-)

Indeed, it may become clear to any observer that there are serious
terminology problems here, in the sense that people are using words in a
variety of senses without realizing when they do not mean the same thing
as others they are communicating with.

But, just give us some time ;-)

Cheers,

Ed Gerck