- From: Denis Pinkas <Denis.Pinkas@bull.net>
- Date: Tue, 26 Oct 1999 13:36:34 +0100
- 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 UTC