Subject: And the definition of non-repudiation is....?

From: Alfred Arsenault <[email-masked]>
Date: Mon, 16 Aug 1999 21:41:28 -0400

Ed,

	Since you so outspokenly oppose the definition of "non-repudiation"
from ISO 7498-2 which (most of) the group has been working under for
these last few years, perhaps you'd like to enlighten us as to the one
true, correct definition of non-repudiation?  Or is it your assertion
that there is no such thing as non-repudiation, and we should just drop
it from PKIX altogether?

	Always looking to improve my understanding,

				Al Arsenault

-- these comments represent the opinions of the author.  Nobody else.

---

From: "tog" <[email-masked]>
Date: Mon, 16 Aug 1999 19:46:10 -0700

Comments Inline below

Todd
----- Original Message -----
From: Alfred Arsenault <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, August 16, 1999 6:41 PM
Subject: And the definition of non-repudiation is....?

> true, correct definition of non-repudiation?

Actually, I will...

Non-repudiation is a process that puts in place a trust model such that any
event that is "deemed nonrepudiable" is beyond question. It's about the
totality of the trust model that surrounds the envelope of the transaction
and the facilities for evaluating it. Such events are deemed non-repudiated.

> Or is it your assertion

No it's very necessary - However, the reality is that the NR bit, as it sits
today is nearly useless IMHO, because what its intended use is is to signal
that there is something different or "more better" about this instance of a
cert process. What it actually should be is an OID or a blob of data that
can be used to describe why or how this non-repudiated status was awarded to
this entity, since this NR BIT's use is clearly an evidentiary process or
enablement for complex decision processing.

>
> Always looking to improve my understanding

me to!

> -- these comments represent the opinions of the author.  Nobody else.

Ditto

---

From: Ed Gerck <[email-masked]>
Date: Mon, 16 Aug 1999 23:03:56 -0700

> true, correct definition of non-repudiation?

Yes, and what should we do about the expected polemic around such NR
definition, specially since good definitions are usually abstract -- "is this
definition of NR the right one?".  Since this question is inevitable, let me
address it first.

Clearly, this will be a right question.  And I hope that nothing that I have
written or will write here will be interpreted as a claim that my definition of
NR will be the "right" or the only possible one. But, answer we must --
what is "the right one"?

Here, perhaps the only metric we may accept is [Leshniewski]:  "A theory,
ultimately, must be judged for its accord with reality". This is the reason why I
have extensively looked into the question of what nonrepudiation is and what it
is not,  and have so much enjoyed the discussion here with so many different
takes at it from many different participants and perspectives, when comparing
the different legal, technical and linguistic usages of the word "nonrepudiation"
in our reality -- for several stances and observer relationships.

Thus, I think we would need to verify any proposed definition of NR in terms
of its derived results based on different stances and observer relationships,
including other areas besides technical communication processes, such as to
test its usage also when modeling nonrepudiation for legal and social
communication processes -- e.g., power relationships, managerial activities,
contracts, auditing, interpersonal relationships,  etc.  -- because they will all
play a role "before" and "after" PKIX certificates are used and (somehow)
PKIX certs must "glue" to these interfaces.

All this, seems to me, is beyond the PKIX charter, however.  So, we may be
left with a chicken and egg problem unless we try to simplify the question and
simply stay for the moment with a NR definition that says the least we need
to say -- thus, avoiding conflicts with interfaces "before" and "after" PKIX.
For example, no more statements on "falsely denying", "providing", "irrefutable
evidence", etc.

In this sense, I suggest that this WG's definition of NR should be operational,
minimalistic, and cast in terms PKIX variables -- rather than a formal logic
definition valid in general (as I have discussed in the MCG list), or a NR model
(such as I presented here and elsewhere) that is too broad for the cases dealt
with by PKIX in a protocol.

I very much liked Todd Glassey's operational definition of NR sent today to this
list: 'Non-repudiation is a process that puts in place a trust model such that any
event that is "deemed nonrepudiable" is beyond question.'

As I see it, this definition needs some fine tunning but it sucessfully operationalizes
NR in terms of trust -- however, trust is outside the scope of PKIX.  Also, we
need to connect NR to that pesky bit.  So, taking into account that we have more
nonrepudiation states than simply on-off (see my previous msg -- at least three
on states and three off states), we could have something like this in the PKIX spec:

1. Non-repudiation is a process based on a trust model defined in the CPS
and its usage is asserted by setting the non-repudiation bit.

Following this text, a particular usage of NR could have many logical states while a
boolean bit could still be used to define whether a NR service is available or not
in services associated with that cert.

An alternative definition of NR (my preferred choice and one which I have stated
already, before) would be to negate any semantics to the NR bit beyond its own
syntatic expression in PKIX itself as a boolean bit, while defining NR as a
qualified pointer (i.e., not as a dangling clause): "Non-repudiation is defined in
the CPS.".  The resulting text in the spec would be:

1'. Non-repudiation is defined in the CPS and its usage is asserted by setting the
non-repudiation bit.

Definition (1') includes definition (1) as subcase.  Either of these two NR
definitions would allow for logically consistent CPSs because anyone writing
a CPS could use this list's archives and adequate legal counsel in order to verify
what a "non-repudiation service" could or could not provide in each particular
case -- for example, for a company acting as a CA in its own interest or as a
commercial CA acting on behalf of the subscriber.  Also, the CPS could define
the validation services required for that NR service during the lifetime of the
cert, in accord to risk/cost, and any other issues that may be relevant to
nonrepudiation for each case -- such as insurance, jurisdiction, legal capacity,
maximum cumulative coverage, delay time to maturation, etc.

In terms of text changes, either of these two NR definitions could directly
substitute the following legacy paragraph in 2459, in its entirety:

    "The nonRepudiation bit is asserted when the subject public key is
     used to verify digital signatures used to provide a non-
     repudiation service which protects against the signing entity
     falsely denying some action, excluding certificate or CRL signing."

(ie, deleting the above paragraph).

NOTE: Since nonrepudiation is not used in PKIX itself, the situation that results
from (1) or (1') is much better than X.509/PKIX usage of the concept of trust
itself -- which is defined a posteriori in the CPS but used a priori in the specs.
This is one more reason to prefer (1') over (1), IMO -- because, since (1) < (1'),
nothing is lost in either in expressive capacity or in coherence when (1') is used.

> Or is it your assertion that there is no such thing as non-repudiation, and we
> should just drop it from PKIX altogether?

No, and never was. In fact, I have been stressing that this discussion is important
also because the concept of  nonrepudiation is IMO logically needed and cannot
be subsummed under authentication.

As Tony Bartoletti wrote today: ".. it seems that in a contract or transaction of
such value that NR becomes a goal, its benefits could be applied to any and all
of these usages [data authentication, endpoint authentication, digital signature]."

So, if NR can be applied to any and all of such services then this also indicates
that NR cannot be of the same type of any of them. Thus, in a geometric
model, non-repudiation is in an orthogonal axis to authentication -- not a
"better" or "stronger" authentication act or, even, an improvement over
authentication.  NR is, simply, different than authentication -- apples
and speedboats.

That is why I commented elsewhere that NR is not a "stronger" type
of authentication and that usage of such concept would lead to
contradictions -- e.g., since nonrepudiation evidence (even if cryptographic)
can always be repudiated by authentication evidence (even if
non-cryptographic).

Cheers,

Ed Gerck

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 17 Aug 1999 12:54:08 -0700

I support your efforts here, Ed. You are making PKIX
work, with the NR bit issue. As PKIX-QC is pushing
the envelope on NR beyond its current vague state,
and given we are in the final call review
of PKIX QC, it is appropriate to comment, and suggest
refinement.

I would encourage that the amendments be
made in the context of PKIX-QC, however, not
2459.  Though 2459 profile is clearly broken (linking
NR to a digital signature mechanism, and denying such
as the audited/signed/timestamped Authenticode
application the legitimacy of NR status) its
not really worthy fixing at this state of minimal
market acceptance of the specification.

Getting PKIX-QC right is worthwhile; it
and can "amend" 2459 for all practical
purposes, and state the general
case it assumes when mandating
use of the NR bit as the means
to show that a signature device
meets the CEC  directive's technical
assurance requirements for electronic
signatures.

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Monday, August 16, 1999 11:04 PM
> To: Alfred Arsenault
> Cc: [email-masked]; Tony Bartoletti; Tod Glassey
> Subject: Re: And the definition of non-repudiation is....?
>
>
>
>
> Alfred Arsenault wrote:
>
> > Ed,
> >

---

From: Ed Gerck <[email-masked]>
Date: Tue, 17 Aug 1999 14:15:14 -0700

Peter:

Thank you.  I agree with you that 2459 is already implictly changed
-- but the change noted by (1') in my msg was made known and
explict in order to be concrete as a suggestion, also for PKIX-QC.

I see that non-repudiation is being mistaken for proof of authentication --
so that there is  a paradigm shift involved here.  The ISO definitions and
also at least two definitions of non-repudiation presented today are IMO
not non-repudiation at  all; they just deal with proof of authentication. It
will take time for us all to sort the different nuances and the discussions
can be very helpful  to bring out the differences between authentication,
proof of authentication and non-repudiation.

But, non-repudiation is that which allows a truthful denial to be thwarted
by a legal affirmation.  This will however just punish the cert user, not the
miscreant -- so that the NR "death penalty effect" will be not be a deterrent
to crime in this case, even for those that believe in the effect.   IMO, using
non-repudiation certificates can actually decrease the security level of a
system -- and I hope to make this point technically clear in a next text.

So, using non-repudiation in a PKIX-QC implementation may not
necessarily mean that a better assurance level will be reached in
business transactions.

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 17 Aug 1999 14:54:18 -0700

At 02:15 PM 8/17/99 -0700, Ed Gerck wrote:
[paraphrasing]

> Non-repudiation is that which allows a truthful denial to be thwarted
> by a legal affirmation.

Now, THERE'S a functional definition! :)

___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