[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: OASIS Registry: Minutes
Thanks for the write-up Sekhar. As you noted, supporting ds for the originator will "enable" non-repudiation (provided we add the other ingredients). Full support for non-repudiation means establishing norms/approaches for non-repudiation. I agree with Sekhar that we probably can't do all this for V2. How about making NR a Type C? We may, though, ensure extending our V2 spec to include NR does not become a problem in the future. Regards, -Suresh -----Original Message----- From: sekhar vajjhala [mailto:sekhar.vajjhala@Sun.COM] Sent: Wednesday, August 29, 2001 12:40 PM To: Patil, Sanjay Cc: Damodaran, Suresh; 'regrep-security@lists.oasis-open.org'; 'dennisc@nii.org.tw'; 'Michael Joya' Subject: Re: OASIS Registry: Minutes "Patil, Sanjay" wrote: > > Attendees: Suresh, Farrukh, Sekhar and Sanjay > ..... > > 1f>NonRepudiation: Can Audit trail support be used here? > We might have to deal with NonRepudiation and Auditing separately. > Action Item: Sekhar to post more details on Non Repudiation. Attached are my notes on non-repudiation. I would strongly recommend that we drop for non-repudiation for V2.0 Sekhar Note on Non-repudiation Non-repudiation provides irrefutable evidence of actions or events of either the sender or the receiver so that the sender or the receiver cannot falsely deny the event or the action at a later time. The evidence could include a. signature (assuming PKI is being used) by the originator. b. trusted time stamp c. signatures of the trusted time service used to sign the trusted time stamp. etc. Such evidence would have to be generated by a sender and transmitted to the receiver. The receiver would be responsible for verification of the evidence. Since the verification of the non-repudiation evidence may occur long after the receipt of the evidence, the information necessary to verify the evidence would have to be stored. Such information could include the public key of the signer of the evidence, public key of any truted time service and so on. Sometimes a trusted third party may need to be involved. The third party could provide services: a. generating of non-repudiation of evidence b. verification of non-repudiation evidence c. storage of evidence that could be made available to an adjudicator in case of a dispute. Furthermore, if a server requires non-repudiation of the client, then this would impose stronger security requirements on the client. The stonger security requirement arises from the fact that the client must make sure the private key is not compromised. And finally, there is an issue of what to if a private a key is compromised. If the private key is compromised, then the client could place the certificate on a CRL ( Certificate Revocation List ). However, the client would not know until the compromise until the server accepts the signature and receives a reply back from the server. There is a lot more to non-repudiation than just digital signatures. I would strongly recommend that we drop non-repudiation for V2.0.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC