RE: [legalxml-courtfiling] Strawman non-repudiation issues

["Nick Pope" <pope@secstan.com>]

Scott,

 

I see a key difference between simple data origin authentication as provided by digitial signatures on their own and non-repudiation is the time factor.  To achieve non-repudiation there needs to be proof of time of the signature independent of the originator.   The signatures used for data origin authentication are checked at the time of the transaction, whilst for non-repudiation the information is to be used for evidence after the event.  Also, I suggest that the proof needs to be linked to evidence of receipt so that there there is no a dispute over whether data has been sent but was never received.

 

Provided the definition of the use of signatures is within our control the inclusion of attatchment is no great difficulty with XML signatures, and is independent of whether data origin authentication or non-repuidation services are provided.

 

Nick 

 

 

-----Original Message-----
From: Scott Came [mailto:scott@justiceintegration.com]
Sent: 28 April 2005 22:57
To: legalxml-courtfiling@lists.oasis-open.org
Subject: Re: [legalxml-courtfiling] Strawman non-repudiation issues

Non-repudiation, in the sense meant so far on Blue, means that the recipient of a message is provided with some mechanism to prove, at some later time, that the message originated with a holder of a private key that matches the public key of some entity certified by a CA to be the holder of same.  (Whew.)  In less obtuse terms, the recipient can later prove that a particular sender did in fact send a message with the specified contents.  This is presumably a requirement for Blue (at least for some messages), no?

XML Signature (a part of WS-Security and therefore the WS-I Basic Security Profile) accomplishes this, does it not?

To address your example, I don't think we had envisioned clerks or judges denying having sent messages...the primary use case is allowing the court (clerk) to have proof that a particular filer did in fact send a (filing) message.  Although filers may want the same assurance on messages coming the other way as well.

A larger issue of non-repudiation (that was once raised but not resolved on the requirements subcommittee) is that XML Signature does not deal with non-repudiation of attachments, which for the short term at least will be the significant part of the "payload" (at least in the WS-* profile.)

> The strawman suggests that message non-repudiation might be provided by WSS.
>
> The WSS SOAP message security 1.0 indicates that (excuse the double
> negative) non-repudiation is a "non-goal". It is particularly not clear to
> me how proof can be provided back to the sender with WSS.
>
> What threat scenarios is the message non-repudation services to protect
> against?
>
> For example is a court considered to be an irrefutable source? If so would
> non-repudiation protection against later denial by the court representatives
> the clerk and judge be appropriate? (Excuse any inappropriate thinking from
> a security technician).
>
> The message reciepts Court and sealing could have a role in providing a form
> of non-repudiation relating to court submissions but it is not clear how
> this fits in with the requirements.
>
> Nick
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php