OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: OASIS Registry: Minutes

+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>


org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh Najmi

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC