legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [legalxml-courtfiling] Strawman non-repudiation issues
- From: "Scott Came" <scott@justiceintegration.com>
- To: legalxml-courtfiling@lists.oasis-open.org
- Date: Fri, 29 Apr 2005 09:12:04 -0700 (PDT)
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
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]