Re: Non-repudiation

Donald,

Thanks for the clarification and the answer to the question. However
... terminology has always been a problem and most of the
misunderstanding is created by different people using the same term
for a different meaning. :-(

The definition I gave is not mine but copied and pasted from an ISO
document, i.e. an internationally agreed standard. So under this
circumstances, it is pretty important *not* to use that term, if you
think it would have a different meaning. So, please, so not use that
term.

Regards,

Denis


> 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 Thursday, 14 October 1999 13:49:54 UTC