Re: Non-repudiation

Neither the requirements document nor the syntax and processing document
will, as far as I can tell, address non-repudiation as your describe it
but both will likely use the term as I have described it.

Donald

From:  Denis Pinkas <Denis.Pinkas@bull.net>
Resent-Date:  Tue, 12 Oct 1999 05:36:58 -0400 (EDT)
Resent-Message-Id:  <199910120936.FAA21760@www19.w3.org>
Message-ID:  <38030EF8.57FB0913@bull.net>
Date:  Tue, 12 Oct 1999 11:35:36 +0100
Organization:  Bull
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
CC:  w3c-ietf-xmldsig@w3.org
References:  <199910111711.NAA12175@torque.pothole.com>

>> 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.
>
>The term "non repudiation" must be used with great care. The ISO
>10181-4 document (called non repudiation Framework) starts with:
>"The goal of the non-repudiation service is to collect, maintain,
>make available and validate irrefutable evidence concerning a
>claimed event or action in order to solve disputes about the
>occurrence of the event or action".
>
>When public key technology and when no mandatory tamper resistant
>hardware token are used, this must remain true even if the signer's
>private key is compromised or declared compromised (and thus
>revoked) after a digital signature has been given. In practice,
>unless time stamping is used, the non repudiation property cannot be
>obtained.
>
>At the last meeting in Oslo I raised the question whether the coming
>document will address non repudiation and, at that time, the answer
>was no. Is the answer to that question still the same today ?
>
>Denis.
>
>
>> 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.
>> 
>> Thanks,
>> Donald
>> 
>> 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.
>> >
>> >Milt
>> >
>> >
>> >-----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.
>> >>
>> >>Donald
>> >>
>> >>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 Tuesday, 12 October 1999 07:46:56 UTC