Subject: Re: MOTION ON NR

From: [email-masked]
Date: Mon, 22 Nov 1999 17:23:15 -0500

Instead of all the legal-psychological speculation about the meaning of
"denial", why not just say what it provides. IMO the critical distinction for an
NR key is that it is intended for persistent signature action *evidence* - not
just for immediate (e.g. session establishment) *decisions.*    Accordingly, I
suggest the following:

1'. nonRepudiation:  for a digital signature verification key that may be used
by a relying party to verify a digital signature, and retained as persistent
evidence of a signer's signature action

How far in the future an NR key is usable a matter of the issuer's archive
policy and practices for the policy under which the certificate is issued, and
any other arguments that one might want to make.

-Gene Hilborn

---

From: Paul Koning <[email-masked]>
Date: Mon, 22 Nov 1999 17:33:10 -0500

I wonder if I'm the only one here who's getting the feeling that this
discussion is, at best, divergent, and at worst, chaotic.  It very
definitely doesn't look like it is heading towards any kind of
closure. 

It certainly serves to reinforce my earlier opinion that the NR bit
should be deprecated on the grounds that there is no possible
consensus on whether it has any meaning, much less what that meaning
is.

	paul

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 22 Nov 1999 18:39:07 -0800

>any other arguments that one might want to make.

Gene,

I think "retained as evidence" is appropriate.  But as (I believe it was)
Ed Gerck who pointed out, there may be applications that require NR for
only the "short term", while others that may arbitrarily decide to have
even NR=0 transactions "notarized in perpetuity" for auditing purposes.

This is just to point out that "long-term vs short-term" is not
(necessarily) the issue.  But perhaps "ephemeral vs evidentiary" is,
where these refer not to length-of-time, but rather "secure retention"
(or not) for any length of time.

Should we not ask what this NR bit is supposed to be saying to:

  1.  The certificate subject (purchaser)
  2.  The relying party
  3.  The CA
  4.  The software folk writing "compliant" products?

Oops.  I almost left out:

  5.  The "Signing Entity", for which NR=1 says "the owner of this
      key is gonna be in REAL trouble when I get through using this."

(I agree with Ed, that any distinction between "signer" and "cert subject"
lies outside of the certification process, so is generally meaningless in
any key usage definitions.  I, too, vote for certificate subject.)

My thought:  If the RP needs to have transactions archived as evidence,
then what is to stop them?  And why should the NR bit be of any special
value to them?  Why should a court of law say that you are "more liable"
because the cert you SUPPOSEDLY own, and whose key you SUPPOSEDLY used,
had its NR-bit set ON?  What it it supposed to be evidence of, and why
is such evidence to be believed?

In a certificate, NR=1 is indeed evidence that its value was NR=1
at the time the certificate was created.  Someone please chime in
with whatever else it is intended to be evidence of.

It seems absurd to me that this bit is intended to be a flag to
applications that they should "archive this transaction as NR".
As if the application does not know a-priori the type of
transaction it is currently processing!  So the only other use
is to have applications that already know they are processing
(NR/non-NR) transactions use the value to demand certs of a
particular NR setting.

But again, why?  Why should the processor of NR-transactions care,
no less require, NR=1 certified keys?  Perhaps there is a better
argument for why the processor of non-NR-transactions would demand
NR=0 certificates, or care.... I mean Really Care.

Someone, please, explain. 

___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: Russ Housley <[email-masked]>
Date: Tue, 23 Nov 1999 09:33:30 -0500

Time and I had hoped to provide language that made everyone equally 
unhappy, yet everyone could live with it.  As you point out, the closure 
that we hoped for did not happen.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Nov 1999 09:31:02 -0500

Gene:

This implies that digitalSignature signatures cannot be retained.  I do not 
agree.  Using Denis Pinkas' usual authentication example: if a 
challenge-response protocol is used to open a door, then the entity that 
opens the door may retain the signed response as part of the audit log.

Russ