Subject: SET and NR

From: "Aram Perez" <[email-masked]>
Date: Thu, 19 Aug 1999 10:33:38 -0700

Having worked on SET a couple of years, I like to put in a few comments on
Bob Blakley's example:

* SET was designed to be a new "input" mechanism to today's existing payment
card infrastructure. Existing mechanisms are "card present" (i.e., when you
hand your card to a waiter) and "card not present" (i.e. when you order from
a catalog over the phone or you pay over the Internet using SSL).

* A typical payment card transaction is as follows: cardholder provides card
number to merchant. Merchant sends the cost and card number to the acquirer
(the merchant's bank). The acquirer sends the cost and card number to the
issuer (the bank that issued the card to the cardholder). The issuer checks
the card number and payment limit. If there is sufficient credit/payment,
the issuer returns an authorization token (and not a "NR token" as Bob
stated) to the acquirer. The acquirer then sends its own authorization token
to the merchant. The merchant now delivers the goods to the cardholder.

* SET deliberately chose not to use the NR bit or digital signatures for any
type of non-repudiation. Why? Because the existing infrastructure already
provides it. And contrary to what Ed Gerck said, I have personally
repudiated phone calls made with my credit card. A while back someone stole
my credit card numbers and made around $250 worth of phone-sex calls (they
were dumb enough to call 800 numbers which traced back to their home phone).
I did not have to pay any of the calls.

* Although there is a mode of SET where the merchant does not get the card
number, the reality is that today most merchants do track transactions by
card numbers. When SET provides the card number to the merchant, it is after
the transaction is approved, not before the transaction (like when you give
your card to a waiter).

* I disagree with Bob's statement that there is "no *proof* of
authentication". The issuer does check that the card number is "authentic"
before sending the authorization token to the acquirer.

* Bob is correct that "there IS non-repudiation evidence" but it exists with
or without digital signatures (or the NR bit).

Regards,
Aram Perez

P.S. Is this message a repudiation of my previous statement that I would not
comment on the NR issue anymore? ;-)

---

From: "tog" <[email-masked]>
Date: Thu, 19 Aug 1999 12:40:55 -0700

Aram, all,
SET was maybe a bad or side-track choice for this conversation since it is
really dead as of this time, even SET II is non-sequitor to some extent.

The real and only issue in the basic thread was and still is "does the
intended use model's for timestamping as per the TS Draft  require a single
NR bit as currently defined for these services, or would an oid or other
structure be mo' bettah'"

That's it.

Todd

----- Original Message -----
From: Aram Perez <[email-masked]>
To: PKIX <[email-masked]>
Sent: Thursday, August 19, 1999 10:33 AM
Subject: SET and NR

> Having worked on SET a couple of years, I like to put in a few comments on

SNIP - Flush - SNIP

---

From: Ed Gerck <[email-masked]>
Date: Thu, 19 Aug 1999 12:40:04 -0700

Aram Perez wrote:

> And contrary to what Ed Gerck said, I have personally repudiated phone
> calls made with my credit card. A while back someone stole

:-) thanks for the bait. Let me repeat what I said, before I comment:

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

2. Credit-card purchases are not repudiable in the case of fraud
by the cardholder, as another example.

3. There are many more case where credit cards are not repudiable.

4. Credit-card purchases are repudiable in the case of fraud NOT
by the cardholder but credit card holders agree to non-repudiation
of a US$ 50.00  charge in the event of card fraud.

The card debt you say is repudiable -- there was fraud and it could be
easily seen that it was not yours.  If the miscreant could not be traced
(for example, used public phones) then you would have to pay the
$ 50.00 fee, but in your case I doubt you paid even that.  However,
if the miscreant never pays the bill I imagine that the credit card will
eventually ask you to pay that $ 50.00 fee.

Cheers,

Ed Gerck

---

From: "Robert W. Shirey" <[email-masked]>
Date: Thu, 19 Aug 1999 16:54:06 -0400

Ed,

In your terms, what is this? And why is that?

non-repudiation service
-----------------------
(I) A security service that provide protection against false denial of
involvement in a communication. (Also see: repudiation.)

(C) Non-repudiation service does not and cannot prevent an entity from
repudiating a communication.  Instead, the service provides evidence that
can be stored and later presented to a third party to resolve disputes that
arise if and when a communication is repudiated by one of the entities
involved. There are two basic kinds of non-repudiation service:

 - "Non-repudiation with proof of origin" provides the recipient of data
with evidence that proves the origin of the data, and thus protects the
recipient against an attempt by the originator to falsely deny sending the
data. This service can be viewed as as a stronger version of an data origin
authentication service, in that it proves authenticity to a third party.

 - "Non-repudiation with proof of receipt" provides the originator of data
with evidence that proves the data was received as addressed, and thus
protects the originator against an attempt by the recipient to falsely deny
receiving the data.

(C) Phases of a Non-Repudiation Service: [For94]'s discussion uses the term
"critical action" to refer to the act of communication that is the subject
of the service, which has five phases:

--------   --------   --------  --------                 --------
Phase 1:   Phase 2:   Phase 3:  Phase 4:                 Phase 5:
Request    Generate   Store     Verify                   Resolve
Service    Evidence   Evidence  Evidence                 Dispute
--------   --------   --------  --------                 --------

Service    Critical   Evidence  Evidence    Critical     Evidence
Request => Action  => Is     => Is       => Action Is => Is
Is Made    Occurs     Stored    Tested      Repudiated   Verified
           and           |         ^                         ^
           Evidence      v         |                         |
           Is         +-------------------+                  |
           Generated  |Verifiable Evidence|------------------+
                      +-------------------+

[For94] W. Ford, *Computer Communications Security: Principles, Standard
Protocols and Techniques", ISBN 0-13-799453-2, 1994.

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 19 Aug 1999 14:38:23 -0700

>Ed,
[snip]

Nice Graph!

Classically referred to as NR, I believe predict Ed will describe it
as a mechanical "Proof of Authentication" scheme.  The contents so
authenticated may or may not be NR, except in the earlier sense of
"mathematically non-repudiable".

The issue, as I still see it, is that any connection to the supposed
"denying entity" is either formal (The Key has your name on it, so
we will take it as being You) or just hoped for, and whether or not
the distinction between these bindings can really rest on the force
of an "I meant to do this" bit.

If the Key with my name in involved in some action, and you collect
and archive the critical evidence, then you can surely prove to a
third party (up to mathematic strength) that it was indeed the Key
with my name that was involved.  So you have (what I have called)
NR in this sense.

But if it can also be proven that I was in a hospital, comatose
during the time the transaction occurred, it seems awkward to me
to claim "Tony's agreement to the action is non-repudiable."

If, for some reason, I can still (formally) be held liable,
then this is the "Non-Rebuttable Presumption" system at work.

But even in this case, NRP rests on top of the mechanical
"Proof-of-Authentication" machine described by the graph,
which could serve to post-verify all manner of activities.

___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: Thu, 19 Aug 1999 16:52:42 -0700

> In your terms, what is this? And why is that?

There is no mention of previous acceptance of non-repudiation liability by signer.
The word false in "false denial" 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.

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

Further, the service does not say it provides what its name denotes --
non-repudiation -- rather, it provides "protection".

In conclusion, the above definition cannot be used to denote non-repudiation, because
of the above mentioned impeditive legal and technical reasons and also because
the service does not say it provides non-repudiation -- even though the service
bears the name of non-repudiation.

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.

For your interest I set out below two clauses from a set of banking terms
recently published by a UK banking organisation for its online banking
business (thanks to Nicholas Bohm, CC'd).  It is typical of the
non-repudiation approach, although more lucid than many.   Note
that any expression of intent or cause are carefully avoided in the text
-- the form used is "until you tell us", where "why you are telling us" or
"what for you are telling us" is avoided.  Also, note the text "even if it
was not given by you" which is a characteristic of non-repudiation --
it is not subject to the proof finding method that you quoted; with
non-repudiation, a truthful denial can be thwarted by a legal
affirmation.

///////////////////////////////////////////////////////////////////////
3.1 We may establish security procedures with you either by post, telephone
or internet (when available).  You must keep your security details and
password secret.  If you make written records of any security details or
password, you must disguise them so that they cannot easily be understood
by anyone else.

3.2 You must tell us as soon as possible if:

you think that someone else knows your security details or password;

you have forgotten your security details or password;

you think that someone else (other than a joint account holder or
authorised person) is trying to use your account.

Until you tell us, you will be responsible for any instruction in writing
or by telephone or internet which we receive and act on, even if it was not
given by you.  Normally we will pay back into your account the amount of
any payments we make after you have told us.  But, if we can show that you
have acted fraudulently or have been grossly negligent or have not kept
your security details and password secret you will be responsible for all
payments we make and all losses on your account.  We will have no other
liability to you.
///////////////////////////////////////////////////////////////////////

Other banks are equally clear that the account holder is only liable
for non-repudiation when in fact they did give or authorize the
instruction to be held under non-repudiation liability (with no
presumption, rebuttable or otherwise). The point is that if I
don't have the power to deny a given capability in advance, it
really isn't non-repudiation -- it's just an option that I can't
control and hence can't be binding, since it isn't voluntary.

> involved.

The description itself says that this is not a non-repudiation service -- so,
there is hardly a doubt that the name is misplaced.

On the other hand, this is a service that collects  evidence of authentication
acts -- the system collects authentication proofs that will operate as evidence
to a resolver. The end result of the system are either evidences (if the
third-party is not included) or a decision based on what is essentially a
rebuttable presumption model.

Again, this is not a non-rebuttable presumption model that would be able to
provide for non-repudiation.

> There are two basic kinds of non-repudiation service:
>

Again, no claim is made to non-repudiation but its name.  The service
provides proof of origin authentication

> protects the originator against an attempt by the recipient to falsely deny

Ditto.  The service provides proof of receipt authentication.

> of the service, which has five phases:

These phases apply for a rebuttable presumption model of validity. Not
for a non-rebuttable presumption model (ie, non-repudiation).

Just to highlight the basic difference, in "non-rebuttable presumption of validity"
or "irrebuttable presumption of validity" or "non-repudiation of validity",
the apparent signer is bound irrespective of the facts (including
proof of non-signing) that it may truthfully prove a posteriori.

But, how does non-repudiation work?

The relying-party has the (legal, technical, etc.) means to deny
the signer's affirmation that the signer did not produce the signature,
irrespective of whether the signer actually produced the signature or not,
or even had the intent to produce it or not, and based *solely* on the fact
that the relying-party could not distinguish the signature from a signature
that the signer did make when the non-repudiation liability was accepted
by the signer.

The relying-party's trust in what was apparently (but not in fact) that
signer's signature will therefore be held by law to be well-founded.
The signer's trust in the reliability of the systems concerned (i.e.,
the signer's trust that only a signature the signer produced will be
treated as binding on the signer) will be held by law to be ill-founded.

Why is non-repudiation useful?

For example, to afford a high-reliance open-loop authorization chain
-- where the signer considers useful to allow a trusted relying-party
to perform its orders with high-reliance and without calling back on
the signer for verification.

As another example, to afford a closed-loop authorization chain
that uses implicit non-repudiation -- as I commented in regard to
SET in a reply to Bob B.

Cheers,

Ed Gerck