W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Re: Non-repudiation

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Mon, 11 Oct 1999 13:11:44 -0400
Message-Id: <199910111711.NAA12175@torque.pothole.com>
To: "Milton M. Anderson" <miltonma@gte.net>
cc: <w3c-ietf-xmldsig@w3.org>

I don't have much disagreement with anything you say.  I've also heard
support for the idea the "non-repudiation" can be considered a
contractual item.  So, for some purposes, it can be obtained even with
shared secret key technology for a class of disputes by a party
contractually agreeing that they can not dispute the signature.

In any case, I think it is easiest for use to continue to use the term
and include a definition if we think it necessary for clarity.


From:  "Milton M. Anderson" <miltonma@gte.net>
Resent-Date:  Wed, 6 Oct 1999 10:30:42 -0400 (EDT)
Resent-Message-Id:  <199910061430.KAA17800@www19.w3.org>
Message-ID:  <010701bf1006$c11b4020$8c3bbfd1@computer>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  <w3c-ietf-xmldsig@w3.org>
Date:  Wed, 6 Oct 1999 10:15:30 -0400

>What the public key security model actually provides is 
>that the signer can fairly successfully claim that other recipients 
>of the document could not have forged the signer's signature.
>The signer can offer evidence that the keys were created under
>proper conditions using trusted key generation software, that 
>the private signing key has been in hardware of an appropriate
>tamper resistance, that the hardware has been connected to 
>a host which has been well-secured, 
>that administrative controls over signing priviledges
>have been properly implemented and enforced, etc.  
>What the public key security model doesn't 
>provide very adequately is for the recipients of the 
>document to prove against the signer's will that only the 
>signer could have created the signature, since the signer
>can reasonably claim that the keys were generated improperly, that the
>private key was stored in an encrypted file under a guessable
>password, that hackers might have invaded the host and planted 
>a trojan horse that created the signature, and that the 
>whole system was haphazardly administered, etc.
>So the second property of non-repudiation can only be
>claimed in closed systems where there is an overall 
>security system design and adminstrative framework 
>that supports it.  It's not a property of public key cryptography
>per se.  
>Unfortunately, the first property, which is more nearly a 
>property of public key signatures, doesn't have a 
>single-word name that I know of.  
>-----Original Message-----
>From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
>To: w3c-ietf-xmldsig@w3.org <w3c-ietf-xmldsig@w3.org>
>Date: Wednesday, October 06, 1999 8:55 AM
>Subject: Re: Non-repudiation 
>>Well, other people think it very important to distinguish the security
>>model provided by, for example, public key versus keyed hash.  One
>>difference in these models is normally called non-repudiation and in
>>technical documents such as this, that refers to the fact that you
>>either need the private key or need to have broken the cryptography to
>>forge a signture.   Having small glossary at the end of the document
>>and defining the term is fine.  But if you want it replaced, I think
>>you should provide a single word substitute that people could agreee
>>on as a replacement.
>>Saying '"non-repudiation" is actually a marketing term!' doesn't
>>persuade me since marketers use and screw up essentially every word in
>>the language.
>>From:  "Chris Smithies" <Chris_Smithies@penop.com>
>>Resent-Date:  Wed, 6 Oct 1999 08:27:14 -0400 (EDT)
>>Resent-Message-Id:  <199910061227.IAA12816@www19.w3.org>
>>X-Lotus-FromDomain:  PENOP
>>To:  w3c-ietf-xmldsig@w3.org
>>Message-ID:  <85256802.0044BD01.00@penop.com>
>>Date:  Wed, 6 Oct 1999 13:35:15 +0100
>>>I would strongly recommend that the term "non-repudiation" and its
>>>derivatives not appear in the draft. From a legal perspective it is seen as
>>>a hollow boast. The only thing that can't be _denied_ is that if a hash can
>>>be decrypted by K1, then it was encrypted by K2. But even allowing that the
>>>surrounding system is completely secure in all respects, it remains
>>>possible for the "appropriate user" of K2 to _repudiate_ a signature
>>>demonstrably signed by K2. Duress... mistake... deception...
>>>"non-repudiation" is actually a marketing term!
Received on Monday, 11 October 1999 13:11:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC