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

Re: Non-repudiation

From: Denis Pinkas <Denis.Pinkas@bull.net>
Date: Tue, 26 Oct 1999 13:36:34 +0100
Message-ID: <3815A052.17028995@bull.net>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
CC: w3c-ietf-xmldsig@w3.org
Donald,

I saw the proposal to use "Signer Authentication" and this seems a
good proposal to me, since no one has ever used it before.

Regards,

Denis

> Personally, I find standards orgnaizations that think they can take
> control of parts of the English language pretty annoying.  We are a
> joint IETF W3C working group.  So far as I know neither the IETF nor
> the W3C is part of our under the control of ISO or even of any
> national official standards organization so we certainly don't have to
> do what ISO says.
> 
> In any case, the main problem has been finding another reasonable term.
> Signer Authentication is a little longer than Non-Repudiation but maybe
> we can settle on using it.
> 
> Thanks,
> Donald
> 
> From:  Denis Pinkas <Denis.Pinkas@BULL.NET>
> Message-ID:  <3803344D.7D8E7B2E@bull.net>
> Date:  Tue, 12 Oct 1999 14:14:53 +0100
> Organization:  Bull
> To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
> CC:  w3c-ietf-xmldsig@w3.org
> References:  <199910121146.HAA21769@torque.pothole.com>
> 
> >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 Tuesday, 26 October 1999 07:37:58 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT