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

["Scott Came" <scott@justiceintegration.com>]

Hi Nick,

Doesn't the timestamping feature in WSS and WS-I BSP address the "time factor"
requirement?  (See WSS SOAP Message Security, v. 1.0, sec. 10, and WS-I DSP sec. 5.3).

Agreed with your
second point...WSS and WS-I BSP handle signing and encrypting of attachments just fine.  This has matured since we
last looked at it on the requirements subcommittee.

Thanks.
--Scott

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