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

Re: Non-repudiation

From: Milton M. Anderson <miltonma@gte.net>
Date: Wed, 6 Oct 1999 10:15:30 -0400
Message-ID: <010701bf1006$c11b4020$8c3bbfd1@computer>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: <w3c-ietf-xmldsig@w3.org>
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 Wednesday, 6 October 1999 10:30:39 UTC

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