|
It is my understanding that we introduced the
Entity Seal that as provided by DSS to help create a new method of
non-repudiation that was separate from the messaging layer. We have also
agreed within Blue that there is a separation between authentication of the
message layer and who actually signs or approves the submission. Using the
message layer security would restrict any possible non-repudiation to just the
sender, which may not be the signer of the documents.
I have not had time to read the documents posted
yet, so I recognize that I have some work to do before I give further comment,
however, for each attachment there needs to be a block of data that includes the
information about who is authorizing or signing the document, and from New
Orleans we agreed to a either a hash or a digital signature per attachment, and
then strongly recommend the Entity seal around the package, and that all these
items be embedded within the envelope, which we now have agreed to in New
Orleans to be embedded in within the body element of SOAP. My
interpretation of this is that what we once referred to as the legalxml root
element is now the body element of SOAP. This does not mean that when you
use SOAP messaging layer you can eleminate the requirements within the
body.
Dallas
----- Original Message -----
Sent: Friday, April 29, 2005 6:21
AM
Subject: RE: [legalxml-courtfiling]
Strawman non-repudiation issues
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
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
|