- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Mon, 11 Oct 1999 13:11:44 -0400
- To: "Milton M. Anderson" <miltonma@gte.net>
- cc: <w3c-ietf-xmldsig@w3.org>
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. 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 Monday, 11 October 1999 13:11:53 UTC