RE: OASIS Registry: Minutes

["Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>]

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.