Subject: Re: Meaning of Non-repudiation

From: "David P. Kemp" <[email-masked]>
Date: Wed, 01 May 2002 10:20:04 -0400

"Housley, Russ" wrote:
> >Tony,
> >
> >I think the PKIX list discussion ended with the observation that there
> >might be more benefit to the NR bit in the other direction, i.e., when it
> >is NOT asserted. In that case the interpretation is that the CA is
> >signalling that the cert was not issued for use in transactions requiring
> >NR. Thus one would normally set the NR bit to 0 in certs to be used for
> >signing authentication data exchanges, vs. binding documents, etc.  When
> >the bit is asserted, it is best viewed as a necessary, but not sufficient,
> >condition for NR.
> >
> >Steve
> 
> Son-of-2459 says:
> 
>        Further distinctions between the digitalSignature and
>        nonRepudiation bits may be provided in specific certificate
>        policies.
> 
> This allows the CA to state what additional meaning is associated with the
> nonRepudiation bit.
> 
> Russ

Russ,

Steve has it (almost) right, and Son-of-2459 has it wrong.
Son-of-2459 should provide *all* the distinction that is needed between
key
usage bit 0 and bit 1:  If bit 1 is not set, then cryptographic
applications
are expected to not generate and not validate a signature on any
document.

The only thing NR=0 should say about a signature is:  "If the hash of
this
authentication exchange happens to equal the hash of the full text of
Romeo and Juliet, it must be a pure coincidence.  The signature
using this cert's key is valid only for non-documents."

The only thing NR=1 should say is: "This is a signature on a document.",
in a manner entirely analogous to the meaning of crlSign=1:
"This is a signature on a CRL".

* No other information about a CRL, such as its validity or its
  applicability to a specific certificate, is contained in the
  keyUsage extension.
* No other information about a document, such as whether a human
  user saw it or whether it is binding, is contained in the
  key usage extension.

Steve should have omitted the word "binding" before "documents".  It is
a
dangerously confusing red herring.

Dave

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 01 May 2002 13:33:37 -0400

Dave:

I am sorry that I replied to this thread at all.  This topic has
been debated before, and the text in Son-of-RFC 2459 is the result of
that debate.  Obviously, everyone can live with that text because no
objections were raised during WG Last Call or IETF Last Call.

I am not surprised that there is not 100% agreement....

Russ

At 10:20 AM 5/1/2002 -0400, David P. Kemp wrote:

Re
Meaning of Non-repudiation1.ems

The following are the message properties:

Encrypted: No

Signed: Yes

Contents Altered after signing: No

Signature Algorithm: SHA1

Russ,

Son-of-2459 should provide *all* the distinction that is needed
between

key

usage bit 0 and bit 1:  If bit 1 is not set, then
cryptographic

applications

document.

The only thing NR=0 should say about a signature is:  "If the
hash of

this

authentication exchange happens to equal the hash of the full text
of

Romeo and Juliet, it must be a pure coincidence.  The
signature

The only thing NR=1 should say is: "This is a signature on a
document.",

keyUsage extension.

key usage extension.

Steve should have omitted the word "binding" before
"documents".  It is

a

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 01 May 2002 13:57:22 -0400

Russ,

I believe we are all sorry to resurrect this topic.
But it is currently the subject of an X.509 defect,
and if the text of X.509 eventually changes in a way
that is incompatible with Son-of-2459, then
Grandson-of-2459 will need to take that into
consideration.

We can all live with the text because we have no
consensus on anything better.  That doesn't rule
out the faint hope that the ITU can develop a
meaningful replacement in the future.

Dave

"Housley, Russ" wrote:
> 
> Dave:
> 
> I am sorry that I replied to this thread at all.  This topic has been debated
> before, and the text in Son-of-RFC 2459 is the result of that debate.
> Obviously, everyone can live with that text because no objections were raised
> during WG Last Call or IETF Last Call.
>

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 01 May 2002 12:16:47 -0800

At 10:20 AM 5/1/02 -0400, David P. Kemp wrote:

>Steve has it (almost) right, and Son-of-2459 has it wrong.  Son-of-2459 
>should provide *all* the distinction that is needed between key usage bit 
>0 and bit 1:  If bit 1 is not set, then cryptographic applications are 
>expected to not generate and not validate a signature on any document.
>
>The only thing NR=0 should say about a signature is:  "If the hash of this 
>Romeo and Juliet, it must be a pure coincidence.  The signature using this 
>cert's key is valid only for non-documents."
>
>in a manner entirely analogous to the meaning of crlSign=1: "This is a 
>signature on a CRL".
>

 From this, it is hard for me to distinguish NR=1 from DS=1.  It seems to 
imply that a digital signature on a "document" (NR=1) is easily 
distinguished from a signature on (say) a "nonce" (for which I assume DS=1, 
NR=0).

But this merely pushes the "wiggle-factor" elsewhere (e.g., distinguishing 
'documents' from 'nonces').

Mechanically, a digital signature provides both data-integrity assurance 
AND sender (signer) identification assurance.  One can argue that both of 
these really come with any digital signature (DS=1) and thus NR=1 adds 
nothing (and NR=0 denies nothing.)  The "mathematical" assurances are 
equally present, so one must be attempting to inject "semantic" with the 
NR-bit.  But "No other information about a document ... is contained in the 
key usage extension" denies even the application of additional semantic.

This leaves little for the NR bit to do ... :)

____tony____

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 May 2002 18:09:27 -0400

Tony:

In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tony Bartoletti
Sent: Wednesday, May 01, 2002 4:17 PM
To: David P. Kemp; Housley, Russ
Cc: [email-masked]; [email-masked]
Subject: Re: Meaning of Non-repudiation

>   user saw it or whether it is binding, is contained in the

 From this, it is hard for me to distinguish NR=1 from DS=1.  It seems
to 
imply that a digital signature on a "document" (NR=1) is easily 
distinguished from a signature on (say) a "nonce" (for which I assume
DS=1, 
NR=0).

But this merely pushes the "wiggle-factor" elsewhere (e.g.,
distinguishing 
'documents' from 'nonces').

AND sender (signer) identification assurance.  One can argue that both
of 
these really come with any digital signature (DS=1) and thus NR=1 adds 
nothing (and NR=0 denies nothing.)  The "mathematical" assurances are 
equally present, so one must be attempting to inject "semantic" with the

NR-bit.  But "No other information about a document ... is contained in
the 
key usage extension" denies even the application of additional semantic.

____tony____

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 01 May 2002 16:24:23 -0800

>NR you are saying that I know what this data is and I am signing it.

Santosh,

I understand the intent (and the utility of this distinction).  What you 
write is what it "should mean" to the signing party, and the relying 
party.  The real question is, what does it mean to the software developer 
who must create a product that applies only the right key at the right 
time?  It is easy to distinguish the extremes, but there are perhaps gray 
areas.

The latter form, "I know what this data is and I am signing it", could mean:

a.  I demonstrate that I was in possession of this material.
b.  I claim to have authored/authorized this material.
c.  I have read these terms.
d.  I have read and understood these terms.
e.  I have read, understood, and intend to abide by these terms.

If I receive an email, and the application pops-up a message that reads, 
"The sender has requested a return receipt to indicate you have received 
this email", which form of signature should apply?  What if the pop-up 
read, "... that you have received and understood ..." or "understood and 
will abide by"?

As a software engineer, I believe this is quite a bit fuzzier than (say) 
cert-sign vs CRL-sign, which are highly formalized objects easy to distinguish.

Consider also that there is software that "automates click-through".  In 
essence, it automates (for instance) web-browsing, identifies certain 
"buttons" and issues the "click" for subsequent action, even with no human 
present.  Thus, it is problematic to assume that (say) a GUI can be 
restricted to, or imply, activities requiring "human intervention".

___tony___

---

From: "Omer Hasret" <[email-masked]>
Date: Thu, 2 May 2002 10:46:14 +0200

Comments in between,

>time?  It is easy to distinguish the extremes, but there are perhaps
gray 

Even if it is like Santosh says for the signing and the relying party,
my opinion is that it is not enough. I also think that the meaning of
these concepts should be the same for all parties including the software
developer.

>e.  I have read, understood, and intend to abide by these terms.

Although I think the options above can be discussed and modified, I
quite agree that we need to have some options that explicitly state what
this signature is for. And rather than having this specified within the
CP, which will definitely lead to different understandings of the same
signature for different PKI domains, I'd like this distinction is made
within the certificate. (If possible) Then, I would be much more
comfortable using my private keys.

Regards,
Omer

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 02 May 2002 11:26:56 +0200

Dave,
 
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509 defect
that has been officially raised.

> Grandson-of-2459 will need to take that into

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be provided
and we are (nearly) all saying the same thing using different words. Santosh
in a subsequent e-mail provided one of these explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used to
authenticate data (this does not mean that the signer has read the data).

Now, there are cases where, beyond the fact that the signer did know what he
signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says that
the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to the
document and indicates a signature policy that is explicit about the meaning
of all signatures performed under that policy (note that one single meaning
is possible in that case).

3) another signed attribute (using the CMS language) is signed in addition
to the document and the previous attribute. It indicates the type of
commitment being made under the signature policy for that signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate Policy
from the CA.

> We can all live with the text because we have no consensus on 
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 May 2002 13:03:08 -0400

Tony:

I am not qualified to go into the legal mumbo-jumbo.  I also think that
naming a bit "non-repudiation" was unfortunate.  I think the user and/or
the application do know if they are signing a challenge as a part of an
authentication process or they are performing digital signature to
provide source authentication.

Thus, we do need two bits: one for authentication protocols and one for
digital signatures.  Whether we rename the current two bits or not, is
up to the group.

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]] 
Sent: Wednesday, May 01, 2002 8:24 PM
To: Santosh Chokhani; 'David P. Kemp'; 'Housley, Russ'
Cc: [email-masked]; [email-masked]
Subject: RE: Meaning of Non-repudiation

Santosh,

write is what it "should mean" to the signing party, and the relying 
party.  The real question is, what does it mean to the software
developer 
who must create a product that applies only the right key at the right 
time?  It is easy to distinguish the extremes, but there are perhaps
gray 
areas.

The latter form, "I know what this data is and I am signing it", could
mean:

will abide by"?

cert-sign vs CRL-sign, which are highly formalized objects easy to
distinguish.

essence, it automates (for instance) web-browsing, identifies certain 
"buttons" and issues the "click" for subsequent action, even with no
human 
present.  Thus, it is problematic to assume that (say) a GUI can be 
restricted to, or imply, activities requiring "human intervention".

___tony___

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 02 May 2002 17:06:13 -0800

>these concepts should be the same for all parties including the software

I agree.  And if we allow this bit to represent something "sufficiently 
mechanical" (ala Tom Ginden's "Technical Nonrepudiation") we might someday 
arrive at a "concept" that all can come close to recognizing.

Unfortunately, the customer expects NR=1 to mean, "If you signed something 
with this key, you shall be unable to repudiate ... something" (that you 
signed, and signed willfully, and signed knowingly, etc.)  This is just too 
foggy for all of the interested parties to come to an agreement, except 
over certain specific types of situations (which would make the NR-bit 
useful to certain communities and not so much to others).

Indeed, in some contexts, NR "trumps the facts".  That is, the holder of an 
NR-signed item can act "as if" you signed it, even if it can be otherwise 
proven that you actually did not.  In this context, you have entered into 
an agreement that "you will abide by the outcome, irrespective of intent or 
even of involvement."  This is (loosely) analogous to the $50 you agree to 
forfeit if your credit card is abused, irrespective of who actually used 
it, how it was subverted, etc.

Cheers!

___tony___

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 May 2002 08:55:55 -0400

Folks:

I am a bit confused.  I have NOT said that NR = 1 means non-repudiation.
All I have said is that we have two bits.  They may be a bit of
misnomer.  We should use one bit for signing challenges for
authentication and another one for signing data for the purposes of
"source authentication" and "data integrity"

What we call them is up to us.  Thus, we should offer implementations
flexibility of having two bits.

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]] 
Sent: Thursday, May 02, 2002 9:06 PM
To: Omer Hasret; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

At 10:46 AM 5/2/02 +0200, Omer Hasret wrote:

>these concepts should be the same for all parties including the 
>software developer.

I agree.  And if we allow this bit to represent something "sufficiently 
mechanical" (ala Tom Ginden's "Technical Nonrepudiation") we might
someday 
arrive at a "concept" that all can come close to recognizing.

Unfortunately, the customer expects NR=1 to mean, "If you signed
something 
with this key, you shall be unable to repudiate ... something" (that you

signed, and signed willfully, and signed knowingly, etc.)  This is just
too 
foggy for all of the interested parties to come to an agreement, except 
over certain specific types of situations (which would make the NR-bit 
useful to certain communities and not so much to others).

Indeed, in some contexts, NR "trumps the facts".  That is, the holder of
an 
NR-signed item can act "as if" you signed it, even if it can be
otherwise 
proven that you actually did not.  In this context, you have entered
into 
an agreement that "you will abide by the outcome, irrespective of intent
or 
even of involvement."  This is (loosely) analogous to the $50 you agree
to 
forfeit if your credit card is abused, irrespective of who actually used

Cheers!

___tony___