[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: OASIS Registry: Minutes
I am forwarding the note that I was unable to send to regrep-security mailing list. Sorry if this is a duplicate. Sekhar -------- Original Message -------- From: sekhar vajjhala <sekhar.vajjhala@Sun.COM> Subject: Re: OASIS Registry: Minutes To: "Patil, Sanjay" <SPatil@iona.com> CC: "'Damodaran, Suresh'" <Suresh_Damodaran@stercomm.com>,"'regrep-security@lists.oasis-open.org'" <regrep-security@lists.oasis-open.org>,"'dennisc@nii.org.tw'" <dennisc@nii.org.tw>,"'Michael Joya'" <mike.joya@xmlglobal.com> "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