Re: OASIS Registry: Minutes

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

+1 on all thoughts related to NR by Sekhar and Suresh.

"Damodaran, Suresh" wrote:

> 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.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard