RE: Non-Repudiation - A Lower Level?

I think I sent this out before. Non-repudiation, from RFC 2828, is defined
as:

http://www.ietf.org/rfc/rfc2828.txt?number=2828

steve

----------------------------------------------------------------------------
-------------
   $ non-repudiation service
      (I) A security service that provide protection against false
      denial of involvement in a communication. (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 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: Ford [For94, For97] uses
      the term "critical action" to refer to the act of communication
      that is the subject of the service:

      --------   --------   --------   --------   --------   . --------
      Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6:
      Request    Generate   Transfer   Verify     Retain     . Resolve
      Service    Evidence   Evidence   Evidence   Evidence   . Dispute
      --------   --------   --------   --------   --------   . --------

      Service    Critical   Evidence   Evidence   Archive    . Evidence
      Request => Action  => Stored  => Is      => Evidence   . Is
      Is Made    Occurs     For Later  Tested     In Case    . Verified
                 and        Use |          ^      Critical   .     ^
                 Evidence       v          |      Action Is  .     |
                 Is         +-------------------+ Repudiated .     |
                 Generated  |Verifiable Evidence|------> ... . ----+
                            +-------------------+

      Phase / Explanation
      -------------------
      1. Before the critical action, the service requester asks, either
         implicitly or explicitly, to have evidence of the action be
         generated.
      2. When the critical action occurs, evidence is generated by a
         process involving the potential repudiator and possibly also a
         trusted third party.
      3. The evidence is transferred to the requester, or stored by a
         third party, for later use if needed.
      4. The entity that holds the evidence tests to be sure that it
         will suffice if a dispute arises.
      5. The evidence is retained for possible future retrieval and use.
      6. In this phase, which occurs only if the critical action is
         repudiated, the evidence is retrieved from storage, presented,
         and verified to resolve the dispute.



-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Cutler, Roger (RogerCutler)
Sent: Saturday, May 18, 2002 11:54 AM
To: www-ws-arch@w3.org
Subject: Non-Repudiation - A Lower Level?


The last con call had some discussion of non-repudiation in which Joe
emphasized that non-repudiation is about convincing a third party that
something happened involving the two direct participants in a transaction,
and others talked about the legal aspects -- such as problems guaranteeing
legal validity over a seven year period in the face of evolving technology.
And a rather complete discussion of non-repudiation has been posted but for
some reason I don't seem to be able to find it at the moment.  (Sigh.)
I would like to suggest a different understanding of non-repudiation that I
think is useful in a lot of business cases.  In fact, beyond "useful" to
"crucial".  Perhaps it is confusing to call it the same thing, but I don't
know what else to name it. Quoting from the EDI-like usage case I am
drafting,
Non-Repudiation is of particular importance, although in practical terms
less in terms of a legal process than simply the ability to say, "You got
this invoice on March 24, and here is your signed confirmation of receipt".
That is, by far the most common scenarios that require non-repudiation
involve people in both companies trying, in good faith, to sort out what has
gone wrong in some screwed up transaction.  What is required in these cases
is an unambiguous record, not rock-solid legal proof.  Taking these issues
to court is a very rare occurrence given an ongoing trading relationship
between businesses.
I believe that it is fair to say that in practical, EDI-like transactions
this sort of "unambiguos record" doesn't just satisfy the 80-20 but more
like the 99.9.  There is NO WAY that any technology or standards are going
to prevent screwups and confusion in business transactions, which in
practice happen all the time.  "You didn't pay us."  "Yes we did."  Or "We
ordered this but didn't receive it."  There are a bazilion things that can
go wrong which have nothing whatsoever to do with the web services or
business protocols, and have nothing to do with anybody taking anything to
court.
Now one might well say, "Well, if one satisfies the more rigorous, legally
motivated requirements of non-repudiation, one also satisfies this lower
level requirement".  That's OK, but what I am concerned about is that the
higher level of non-repudiation may be difficult to achieve.  I believe that
there is a genuine and immediate need for the sort of non-repudiation
described above, and perhaps it could be useful to get quickly to such an
understanding.
Or am I perhaps talking about what some people are calling "auditing"?  I'm
afraid I have not been entirely clear what people have meant by that.  Am I
really asking for clarification of terminology rather than a different
understanding of requirements?

Received on Tuesday, 21 May 2002 11:23:40 UTC