Subject: RE: Meaning of Non-repudiation

From: "Aisenberg, Michael" <[email-masked]>
Date: Fri, 26 Apr 2002 12:37:08 -0400

As an under-initiated tech-wanabe lawyer who has observed the
'non-repudiation'
debate for several years, it occurs to me that, not only do I concur in
Todd's observation
regarding the use of NR {as a technical bit-descriptor being problematic
vis-à-vis
his described more 'comprehensive' view of  NR as a 'condition' achieved
through the
deployment of an IA environment}, but would further suggest that even
THAT interpretation requires
calibration against the generally accepted legal concept of
non-repudiation
inherent in the construct and case law around UCC secs. 2-609/2-610.

Todd's analysis suggests a non-statutory analog --based on a description
of a
complex of conditions existing simultaneously-- that provides a
technology-grounded basis for asserting
the same absolute of  'undeniability of existence' that the
legal/statutory phrase implies (but, lawyers would never
assert with the same absolutism as, say, a law of physics, unless a
court of last resort had
ruled!)--but it is of course still different from, and therefore capable
of being confused with the
bit descriptor.  All of which is a long-winded way of stating the
obvious--that the importation
of 'terms of art' from one discipline to another is risky--absent
precise equality of
definition, intent and usage--which we obviously don't have here......

Michael Aisenberg
--VeriSign/D.C.--

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Friday, April 26, 2002 11:49 AM
To: Tom Gindin
Cc: PKIX-IETF
Subject: Re: Meaning of Non-repudiation

Tom,
I agree with you - the X.509 model is broken too. NR is a bigger thing
than
a bit in a data structure and using the term NR causes problems for
auditors
and other professionals that would have to use these protocols.

I and many others define NR as the sum-total of all the Information
Assurance technologies, techniques, and practices that make up and
operating
environment. Thus NR is a state specific to a totality of condition and
maybe needs essentially gradiant levels rather than a binary on or off
state. Thats why a single bit alone without the accompanying OID is of
questionable value here.

Todd

----- Original Message -----
From: "Tom Gindin" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 11, 2001 3:50 PM
Subject: Re: Meaning of Non-repudiation

>
>      IMHO, if X.509 had not been calling the bit in KeyUsage
> "non-repudiation" for some years, I would prefer to put "Persistent
Data
> Authentication" into KeyUsage and define several different flavors of
> non-repudiation in ExtendedKeyUsage, profiling non-repudiation
services in
> parallel with those ExtendedKeyUsage values.  This would also allow us
to
> define different levels of NR and put them into certificates in a
natural
> way.  However, they have been calling the bit "non-repudiation", and
I'm
> not sure we can change its meaning on the installed base of
certificates
> and on the X.509 group without an unusual level of unanimity and
> near-certainty that it won't break anything.
>
>           Tom Gindin
>
>
>

---

From: Aram Perez <[email-masked]>
Date: Fri, 26 Apr 2002 11:37:59 -0700

Maybe Hoyt can comment. If I understood him correctly, he mentioned to 
me that he had talked to a few people during the RSA Conference and that 
there was a consensus to have the NR bit renamed at the X.509 level.

Regards,
Aram Perez

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Fri, 26 Apr 2002 17:58:42 -0700

i have been talking to people about this bit for sometime. we did 
discuss it at the meeting in geneva in early march and i did discuss 
the issue at the american bar association meeting information 
security meeting just before that (and yes at the rsa meeting also)

the choice of non-repudiation for the name of the bit so long ago is 
unfortunate since so many interpretations have sprung up. i still 
believe that the intent was to signal "more" than just providing a 
signature for proof of origin. at the time i suggested that what 
"more" is would be understood from policy. i still argue that a bit 
is not enough to convey all the shades of meaning desired.

i think that "more" means some sort of "not only is this proof of who 
i am, but also,scout's honor, i really mean what i say in this 
message". i argue that the text that in 509 that that the 
nonRepudiation bit does not have to be set in certificates used to 
support signing a crl shows our intent when we wrote this text 10 
years ago, albeit poorly. that is, one doesn't have to signal "more" 
when signing a crl because cRLsign = digitalSignature + 
nonRepudiation - not only can it be proven that the proper entity 
signed the message but that it intends to stand by the content of the 
message.

it's clear that when one talks to lawyers long enough, an agreement 
that looks rock solid to engineers looks like swiss cheese to lawyers.

even if the systems could be made so unbuggerable that one could 
honestly swear in court that what was signed was what was presented 
to the reader, a lawyer could still argue about intent (i.e., i meant 
to do it and i understood the consequences of doing it). i firmly 
believe it's still a good goal to try to build that unbuggerable 
system because improved systems should focus the legal argument (but 
i suspect a lawyer will still try to throw everything into question 
if that helps the client).

if this stuff gets used frequently and the public accepts its correct 
operation as an everyday tool of life, then focus on the technology 
may go away. today it would take a rare lawyer to drag in telephone 
service providers and experts in order to convince a judge or jury 
that there is no proof that the plaintiff's telephone call to the 
client actually went to the client (of course internet telephony may 
make this an arguable point again). maybe after a 100 years the 
public will consider electronic contracts and agreements just another 
tool of everyday life.

so, if we really cannot declare something nor-reputable with just the 
stroke of a bit, should we just forget the whole thing?

i think that it might be useful to signal that the ca expects this 
certificate to be used as more than just source of origin 
authentication. can such a signal be a two state flag? maybe, but it 
could be a lot of semantics to put on one small bit. however, the bit 
could be used to signal the "more" status with an understanding that 
the precise conditions and constraints will be specified elsewhere, 
e.g. policy. a lawyer i work with on the isc suggests the phrase 
"necessary but not sufficient condition".

does this need to be fixed in x.509? YES. however, i suspect that 
changing the name would be merely a placebo and later on, we will 
still find that all is not well.

i have suggested to the directory group that, even though the 
discussion will probably be painful, we should clarify the text 509. 
however, i don't think this is something to fix by defect processing 
but in the new edition currently under development.

i hope that you people and the isc would be very active in the 
development of that text.

    hoyt

At 11:37 AM -0700 4/26/02, Aram Perez wrote:
>Maybe Hoyt can comment. If I understood him correctly, he mentioned 
>to me that he had talked to a few people during the RSA Conference 
>and that there was a consensus to have the NR bit renamed at the 
>X.509 level.
>
>Regards,
>Aram Perez
>
>

---

From: "todd glassey" <[email-masked]>
Date: Sat, 27 Apr 2002 10:58:33 -0700

Aram - yes you are rignt in your commentary regarding the analog and needing
a metric to measure the verying state of NR with.What I would suggest is
that these are states that are based in "grade of reliability" and that
these are technologies that that need to be codified in concert with the
audit community since they will really be the source of the metric.

What this will allow to occur is that stateful information as to the
integrity of the surrounding system can be made part ofthe trust negotiation
process (one of those Mythical "Transaction Service Models" that Stephen is
so fond of hammering me for)...

The end point of this is that it brings to light something critical and that
is the concept that Audit and Audit Process (or state data) needs to be
included inside of the PKI process so that total machine processing of PKI
enhanced transactions can take place. This is another argument for all of
the concepts that I proposed:

    1)    Adding a need for a use model to all I-D/RFC/Standards Drafts

    2)    Building bridges between us and the other standards groups
affected by PKI... especially to the auditors.

    3)    And finally the realization that it is the Audit Process and its
model that determines the end makeup of the PKI product - Not us.

Todd

----- Original Message -----
From: "Aram Perez" <[email-masked]>
To: "PKIX" <[email-masked]>
Cc: "Hoyt L. Kesterson II" <[email-masked]>
Sent: Friday, April 26, 2002 11:37 AM
Subject: Re: Meaning of Non-repudiation

Regards,
Aram Perez