Subject: Re: Meaning of Non-repudiation

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 06 Apr 2001 15:52:01 -0600

Alas, poor Dave, you have fallen into the black hole of PKI, from which there is no escape.

Having written several megabytes of e-mails on the subject over the last ten years or so, and having read countless more on this topic from others on this list and elsewhere, if you were merely some grad student trying to get a crib for a term paper, or if your company were one of the few remaining dot coms no one ever heard of, I would refer you to the archives, probably starting with Tom Ginden's RFC.  But you are not, and Identrus is at least potentially a very major player in this space, so you deserve a more extensive reply. Be careful what you ask for!

The one sentence answer, IMHO, is that the NR bit in X.509 is neither necessary, nor sufficient, nor entirely useless; nor is any given set of proposed semantics agreed upon by any particular group of lawyers, technologists, or relying parties. -- at least if the number of people in the group exceeds three.  As you may have noticed, the 2459 definition of NR is very nearly circular, except for the fact that "non-repudiation service" is not defined or agreed to by anyone, at least in any meaningful sense.

Why do I say that the NR bit is not necessary?  Because, at least in the US, the marvelously muddled eSign legislation says that parties can agree to just about anything, probably including smoke signals, as a legally binding signature if they choose to do so.  On the other hand, absent such an agreement in advance, there is no clear standard as to what is or should be required to make a digital signature legally binding. and enforceable.

OK, why is the bit not sufficient?  That's even clearer.  Despite what technologists might think there is (almost) no such thing as nonrepudiation, as your legal counsel has undoubtedly already advised you.  Physical duress, fraud, incompetence, lack of authority or agency, illegality of the act -- all these things and more are examples of why any agreement, signed or not, can be repudiated or made invalid.  Now with respect to a digital signature itself, there are a number of other defenses that might be possible, including the lack of knowledge that anything was being signed at all (a malevolent program was executed which caused some thing to be signed that the user was not aware of); insufficient protection given to a key that was not intended for important legal matters, allowing the key to be compromised; incorrect binding of a name to a key (that's my name, but that's not my key) by the CA; lack of archived CRL or OCSP checking by the relying party, making it impossible !
to prove that the signature was ostensibly valid at the time of issuance.

So if the bit is neither necessary nor sufficient, is it completely useless?  Maybe, but I believe that an argument could still be made for it, as a API signal to the originator's software.

What I would like to see the bit used for at this late date is to serve as a signal to the signing party's software that this certificate, and therefore the associated private key, is something special, and that particular care should be taken with it.  For example, it would be reasonable to use this as a signal within a smart card that the PIN or other identifier must be reentered every single time the private key is used, so that the system software can't sign two or more things after the key is unlocked.  The bit could also be used to bring up various dire warnings, cautioning the user to be really, really sure that he knows what he is doing, thereby confirming the user's conscious and willing intent.

Of course this same meaning could be applied to a bit in an attribute associated with the private key -- it wouldn't have to appear in the certificate.  But if such a use for the NR bit were to become widespread, it would at least serve some useful purpose, as it would help to rebut the argument "but I didn't know I was signing anything at all, much less something this important."

Now there are some people whom I respect that would argue that nothing is going to be settled in this area until some legal ruling is upheld with respect to the matter.  My general feeling, however, is "God forbid!"

I'm sure you're aware of the saying "hard cases make bad law."  The only thing that I can imagine that would be worse than the demonstrated impossibility of having to educate entire House and Senate, plus their respective staffs, about PKI would be the prospect of some randomly chosen plaintiff's attorney and some other randomly chosen defense attorney arguing the fine points of PKI in front of a clueless judge and an equally clueless jury, and having the outcome of that process end up setting a national precedent.  Ouch!

What we need in this environment is the equivalent of the Generally Accepted Accounting Principles, which are rules adopted by accountants and auditors on behalf of the people who pay them to make sure that some company isn't playing fast and loose with the facts.  We don't necessarily need a law, or a definitive court case -- we just need a sufficient strong set of customers who can step up and say "do it this way, or we aren't going to believe you" and make it stick.

So far, no constituency has developed that has that amount of clout, and both the legal and the technical community have sort of agreed to duck the issue for now.  SSL, for which  perhaps 97% of all certificates have issued, doesn't sign documents, and the use within the S/MIME community has so far been quite slow to pick up. 

Perhaps Identrus and their community of interest will eventually be able to marshal that amount of clout and make it stick -- I rather hope so. But I am afraid that if you look to the existing stakeholders for a definitive agreement, you are going to be waiting a long, long time.

Regards,

Bob

>I am trying to clarify the meaning of non-repudiation (as defined by the
>technology standards) for our legal counsel. 2459 says this about
>non-repudiation:
>     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.
>
>The question is what does "some action" mean? Is the action merely signing
>the transaction? Or, is the action perhaps committing to the terms described
>in the signed transaction?
>
>To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
>this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
>am committing myself (or my company) to the terms described herein?
>
>Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
>ISO/IEC 10181-3:...1), Information technology - Open Systems Interconnection
>- Security Frameworks in Open Systems - Non-repudiation framework)? Can
>anyone snip a description of non-repudiation from X.813?
>Thanks!
>Dave Oshman 
>Senior Vice President 
>Technology 
>Identrus LLC

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 06 Apr 2001 17:24:20 -0700

>Alas, poor Dave, you have fallen into the black hole of PKI, from which 

Also Known As, the point of No Return (NR).

(I feel as a moth drawn to a flame.)

I think Bob has laid out the issues very nicely regarding the (lack of) 
necessity, sufficiency, and (arguable) usefulness of the "NR" bit.

My feeling is that if the NR bit says anything at all, it is the issuing CA 
that is speaking.  I cannot go to a (reputable) CA, and ask for a key to be 
certified with any attributes of my choosing.  There is some understanding 
(modulo CP/CPS) that the CA "stands behind" the attributes contained in the 
certificates they issue, at least in terms of their having followed their 
(self-defined) process.  (Beats me just what this is worth...).

The most I can hope is that, at some future point, the PKI Protocol Players 
come to agree upon some common standard of certificate issuance processing 
"guaranteed" by inclusion of the set NR bit.  Even then, it will be little 
more than one more piece of evidence that may be provided in case of a dispute.

I have thought about how far one could really go, in making the NR-bit 
stand for what folks naively expect it to be.  My "program" addresses both 
issuance and usage.  (It may seem "humorous", but I wonder how far off this 
will really be.)

Issuance of NR-bit Certificates:
--------------------------------

The NR-bit Certificate shall contain or reference:

1.  The CA-signed audio file of the certificate subject, reading aloud the 
CA's CP/CPS verbatim, and correctly responding to several randomly selected 
questions about this material.

2.  The CA-signed photograph of the certificate subject shaking hands with 
the CA president under a banner that reads "Another Satisfied NR Customer".

Usage of NR-bit Signature Keys:
-------------------------------

These keys will be contained in biometrically-sensitive key-cards that self 
destruct under reasonable signs of tampering.

The keys/key-cards can be used in any of the "Signature Kiosks" that we 
expect will replace the common "auto-teller" machines.  These kiosks will 
be operated by the major banks, and serve as "secured web portals".  Users 
will be able to insert their NR key-card to conduct transactions that would 
otherwise require the presence of two witnesses and a roomful of lawyers.

Prior to reaching the "signature preparation phase" of a transaction, the 
terms of agreement may be perused at the user's leisure.  To enter the 
"signature preparation phase", the user must place their thumb, palm, or 
otherwise previously-registered part of their warm body in full contact 
with the key-card's "bio-read" surface, so that authentication and 
biometric stress data can be recorded.  The user is then presented with 5 
randomly selected multiple-choice questions about the terms of the 
transaction.  The user must answer all questions correctly in order to 
proceed to the actual signature phase.

Note:  The card will refuse to unlock the contained NR-key if:

a.  Bio-authentication fails (fingerprint, DNA-read, etc).
b.  Excessive alcohol or other mind-altering elements are detected.
c.  Skin-galvanic properties detect undue psychological stress.

Once all of these simple measures are in place, you will be able to walk 
down any city street, stop at a signature kiosk, withdraw some cash, 
purchase some postage stamps, and close escrow on that house you've been 
eyeing...

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Aram Perez <[email-masked]>
Date: Sun, 08 Apr 2001 21:47:19 -0700

Bob Jueneman wrote:

> Having written several megabytes of e-mails on the subject over the last ten
> years or so, and having read countless more on this topic from others on this
> list and elsewhere, if you were merely some grad student trying to get a crib
> for a term paper, or if your company were one of the few remaining dot coms no
> one ever heard of, I would refer you to the archives, probably starting with
> Tom Ginden's RFC.  But you are not, and Identrus is at least potentially a
> very major player in this space, so you deserve a more extensive reply. Be
> careful what you ask for!

Dave should read the archives, specially since he is from Identrus.

> 
> The one sentence answer, IMHO, is that the NR bit in X.509 is neither
> necessary, nor sufficient, nor entirely useless;

I agree with most of what you wrote except, as I have previously stated, I
strongly believe the bit is useless. More below...

[snip]
> 
> So if the bit is neither necessary nor sufficient, is it completely useless?
> Maybe, but I believe that an argument could still be made for it, as a API
> signal to the originator's software.
> 
> What I would like to see the bit used for at this late date is to serve as a
> signal to the signing party's software that this certificate, and therefore
> the associated private key, is something special, and that particular care
> should be taken with it.  For example, it would be reasonable to use this as a
> signal within a smart card that the PIN or other identifier must be reentered
> every single time the private key is used,

The problem is that nothing prevents me (or any other person) from having
more than one certificate for my public key. So I can have one certificate
with NR and the other without NR.

> so that the system software can't
> sign two or more things after the key is unlocked.  The bit could also be used
> to bring up various dire warnings, cautioning the user to be really, really
> sure that he knows what he is doing, thereby confirming the user's conscious
> and willing intent.
> 
> Of course this same meaning could be applied to a bit in an attribute
> associated with the private key

I agree that this is where it belongs, but the few crypto APIs (partial
list: PKCS#11 and CDSA) that support private key attributes treat the
attributes as optional and don't define a specific NR attribute.

Regards,
Aram Perez

[snip]

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 09 Apr 2001 14:00:39 -0400

> (I feel as a moth drawn to a flame.)

How true - sigh :-(.

Bob Jueneman wrote:
>
> And given that scenario, I continue to believe that the currently
> ill-defined bit should be officially deprecated, and some other
> attributes defined as necessary with a great deal more precision.
> If ISO X.509 and/or the PKIX group refuses to deprecate the bit,
> then certainly the user community should.  IMHO, of course.

And I continue to believe you are correct.  NR should be deprecated,
and replaced with a new name for bit 0:  "Persistent Data
Authentication", which would have the property that was once
called "Technical NR".

As the HAK remark 13.48 says, 
  "A fundamental distinction exists between a party A being
  able to convince itself of the validity of a digital signature
  's' at a point in time t0, and that party being able to convince
  others at some time t1 >= t0 that 's' was valid at time t0."

It is reasonable for certificates to contain keys marked
for various cryptographic purposes, and "Persistent Data
Authentication" and "Entity Authentication" are two distinct
purposes suitable for being so marked.

Philip Hallam-Baker wrote:
> At the meeting the strongest statement that could be agreed upon
> concerning the non repudiation bit was:
>  
> 1) The setting of the non repudiation bit in the certificate was
>    a necessary but not sufficient condition for a relying party to
>    consider a signature to have the non-repudiation property.

Without delving too deeply (and this moth refuses to delve any
deeper), the "PDA" bit is not inconsistent with the ABA statement.

---

From: Polar Humenn <[email-masked]>
Date: Mon, 9 Apr 2001 15:22:06 -0400 (EDT)

> with NR and the other without NR.

Isn't it really worse than that? Nothing prevents your public key being
associated with any other name (DN), keyCertSsign bit, any other
certificate extension, Novel Security Attributes, or otherwise. The only
thing that makes the certificate somewhat believable is *your* trust in
holder of the private key that signed the thing.

Isn't a certificate is merely nothing but a another generic document that
is "loosely"  signed by a private key? That document can mean anything to
the "relying" party.  The certificate key usage bits, extensions, or even
the associated DNs are meaningless without an agreement of interpretation
between all three parties involved (CA included), and probably (as Bob
frequently notes) their lawyers, and subsequent judges and juries, as
well.

What does it matter if it's called nonRepudiation, or keyCertSign, or
digitalSignature? I do not see carrying much weight to the key usage bits
at all. I cannot see how or why it really plays a part any validation
process.

BTW, I find it really bizarre that the digitalSignature bit alone says
that this key, which happens to be in this certificate, is allowed to sign
****ANY**** document EXCEPT for a document that just happens to look like
an X.509 Certificate or CRL. It's as if the X.509 certificate or CRL were
the strongest documents in the world one can sign! Is this correct?

Cheers,
-Polar

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 09 Apr 2001 13:19:36 -0700

>Authentication", which would have the property that was once

I have to agree.  The greatest utility of this bit, a quality over which 
the CA actually has some control, is the commitment to provide for a degree 
of data-persistence.  If such a revision would occur, these discussions 
could actually address something tangible.

___tony___

---

From: Ed Gerck <[email-masked]>
Date: Tue, 10 Apr 2001 16:17:02 -0700

List:

I think there is some agreement, on this page at least. What the current
NR bit is signaling is that there is (somewhere, not necessarily at the
CA) some proof of authentication.  I suggested the name POA (proof
of authentication) at the last time we discussed this.  The POA does not
have to be persistent, though -- it may be valid only for a short time
(in practice we find that a short time correlates well with higher
assurance), some time in the past.

OTOH, we still have the pesky problem of denoting a service that
prevents the denial of an act, which prevention also needs to be
qualified.  Preventing the denial of act X cannot be derived from
affirming act Y, usually, and thus non-repudiation is IMO a necessary
primitive in certification procedures, in the same way (and not less)
that authentication is.

In particular, the oftentimes expressed idea that non-repudiation is a strong
form of authentication, or a persistent form of authentication, is possibly at
the root of this confusion.  It is neither, as we can see by re-reading (if
we must) the NR thread in this listserv.  So, if NR is missing (as it is becoming
clearer) then we are also missing an important part of a our toolkit. Calling
the current NR-bit the POA-bit or the PDA-bit only solves the semantic
problem, not the technical problem. Not very useful, considering the other
semantic problems in PKIX/X.509 that are left untouched (let's talk about
"Distinguished Names"?).

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 10 Apr 2001 18:50:29 -0700

>semantic problems in PKIX/X.509 that are left untouched (let's talk about

Hi Ed!

Good call.  (I guess I need to review those archives ... :)

It would be nice to have concise definitions for PDA (Persistent Data 
Authentication) and POA (Proof of Authentication) in marginally technical 
(read: tangible) terms.  Then, consideration of NR might be more clearly 
understood in contrast.

When you say that POA need not require persistence, do you mean to imply 
that (given short-term POA,) persistence becomes a separate 
chain-of-custody issue?

Do you feel that Tom Ginden's "Technical NR" provides a basis for POA/PDA ?

Do you feel that there is anything else that a certificate could hold (and 
to which a CA would attest) that would move further in support of NR 
capability?  Or is anything beyond a POA assurance the purview of an 
entirely independent service?

Cheers!

___tony___

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Apr 2001 12:20:03 -0400

Folks,

I do not anticipate any change to the NR bit in X.509 nor in PKIX. 
I've read the extended dialogue on this topic and it has a familiar 
ring.  However, many of the arguments put forth seem to be narrow, or 
miss the point entirely.

Yes, it is true that the NR bit is not sufficient for NR. It was 
never claimed to be.

Yes, if suitable, external, contractual agreement exists, the NR bit 
is not necessary for NR.

The main purpose for the NR bit is to allow a cert to be designated 
as NOT being associated with signatures used in NR transactions. This 
is a safety feature for the EE. By using a cert with the NR bit set 
to FALSE, the EE is explicitly stating that the signature generated 
with the corresponding private key is not be be considered binding, 
e.g., it is for authentication but not for non-repudiation.  Yes, if 
the user has multiple certs with the same key and the NR bit is set 
in some but not others, this utility is voided. In general we can't 
prevent users from engaging in such behavior. An RP that holds a copy 
of the cert used in a NR transaction has a defense against such a 
user, if push come to shove.

So, I suggest that we table the discussion on the labeling of the NR 
bit and leave the more detailed discussions of how to achieve 
technical NR to the relevant documents, of which 2459 (its successors 
and assigns ...) is not one.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 11 Apr 2001 13:04:08 -0400

> I do not anticipate any change to the NR bit in X.509 nor in PKIX.

Fair enough.  But if the name of the bit is not changed, then the
definition must be clarified, to avoid the ambiguity evident below:

> e.g., it is for authentication but not for non-repudiation.

This is the problem - some people associate the words NR and "binding"
with "creating an obligation".

I agree completely with your "not considered binding", as long as there
is an explicit statement that binding means persistent - i.e., effective
for some time after generation, as opposed to effective only at the
time of generation.  Here is the litmus test: do you agree that in
order to validate a signature on an S/MIME message (any message, for
any purpose, signed by any entity), the NR bit must be set?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Apr 2001 14:22:40 -0400

David,

>any purpose, signed by any entity), the NR bit must be set?

I do view NR as a form of persistent authentication and integrity, 
but not all persistent forms are NR. Using your example, S/MIME 
offers me only one means of providing data origin authentication and 
integrity (at least when using RSA), i.e., signing a hash of the 
message I send. I want to be able to send an authenticated e-mail 
that says "Yes, I'll go along with that proposal" without risking 
that this informal message might later be construed to be a binding, 
non-repudiable communication. The NR bit should allow me to do that. 
I would like to have a different certificate (with a different key 
pair) reserved for transactions where I will be very careful about 
what I sign, where I sign it (not on some random machine with 
software unknown to me), etc.

Steve