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

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

Comments inline...

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

The
key here is to base our implementation of non-repudiation and integrity requirements on XML Signature.  In the Web
Services Messaging Profile, we would get to XML Signature via WS-Security.  Other profiles may use other methods to
represent the hash (a digital signature is, of course, just a specific type of hash), but I think we should consider
using XML Signature in other profiles--why invent a new vocabulary for representing signatures when a perfectly usable
open standard already exists?

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

Dallas, I
don't know what "authentication of the message layer" means.  Hopefully the New Orleans minutes will
illuminate this issue.  I thought we were moving towards using mechanisms like SAML to represent authentication
tokens, and XML Signature for non-repudiation an integrity requirements.

> Using the
> message
layer security would restrict any possible non-repudiation to just the sender, which may not be the signer of
> the documents.

Again, I don't know what "message layer security" means.  Using XML
Signature does not force the restriction you suggest.  Anyone with a digital certificate (private/public key pair) can
sign the SOAP body (or specific parts thereof) and attachments.  Signatures can also be layered (e.g., I sign the
document, you sign the document and my signature, etc.)  In the Web Services profile, using WS-Security, this is
implemented as SOAP headers; other profiles would likely have their own way of structuring the signature information,
hopefully leveraging the XML Signature vocabulary.

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

Each profile needs to handle this requirement; the Web Services Messaging Profile
will handle it via WS-Security.  Those who would satisfy the non-functional requirements via a different profile would
be obligated to specify how that profile would handle it.  I would hope the TC would favor open-standard
implementation mechanisms, like XML Signature or at least S/MIME.

> and from New Orleans we agreed to a
either a hash or a digital signature per
> attachment,

Ditto previous comment.  WS-Security handles
this fine.

> and then strongly recommend the Entity seal around the package,

Please define
term "package".  It would be possible (I think...we should confirm) to create a single signature
(represented as a header using the XML Signature vocabulary) for the SOAP body and all attachments.  Has this notion
of "entity seal" made it into the non-functional requirements yet?

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

Are we abandoning the notion of profiles, or was this decision made in New Orleans
with respect to the Web Services messaging profile?  I would strongly disagree with having the Web Services messaging
profile place signature information in the SOAP body.  This contradicts the WS-Security and WS-I standards.

Even for non-WS profiles, I would suggest a term other than "envelope" here.  It has a specific meaning
for SOAP, and according to that meaning, saying that the "envelope [is] embedded within the body element of
SOAP" is non-sensical.  In SOAP, the envelope contains headers and a body.

> 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 -----
>   From: Nick Pope
>   To:
scott@justiceintegration.com ; legalxml-courtfiling@lists.oasis-open.org
>   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
> 
>
>     -----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