Hi
Peter,
Pls see my response
below.
Rgds
kama
-----Original
Message-----
From: Peter
Larsen Borresen [mailto:plb@itst.dk]
Sent: Thursday,
September 29, 2005
10:40
PM
To: Kama, Kamarudin Bin Tambi;
ubl-tsc@lists.oasis-open.org; ubl-psc@lists.oasis-open.org
Cc: Grace Ng, Swee Lee (T&L); Jern
Kuan, Leong; Fu Wang, Thio
Subject: SV: [ubl-tsc] [Fwd: [ubl-psc]
Proposal for a signature refenrence]
Do I
understand you correctly when that ebXML supports a solution where the
xml-document and the signature are in the same envelope, but in different
payloads?
Kama>> Think you've
misunderstood. COML is not a messaging protocol but a business document. What
we mentioned is that in our solution, the COML approach is independent of the
messaging layer. The digsig is embedded inside the COML document and is used
by the application for multi-signer approval workflows. In ebXML case, the
digsig done in the soap header is only used for the transport
layer.
What I
suggest is that the xml-document becomes able to refer to the signature, not
only as a URL but also as a Mime reference.
Kama>> OK,
noted.
The
problem with embeddign the siganture in the xml-document is
1) it
becomes invalid if it is transformed to an other document.
Kama>> How does
this differ from your proposed approach? Whenever any XML document is being
transformed, the digsig is no longer valid.
2) A
digital signature on a xml document is not valid in legal terms. Only a
transformation of a xml-document can be brought into a court
room.
Kama>> Think lets
not get into the legal aspect of it. Each country will have its own Electronic
Transaction Act. Interpretation might differ from country to
country.
3) A
digital signature with the purpose of ensuring that no one has tampered with
the document has nothing to do in a procurement document. This is a matter for
the transportation layer.
Kama>> This depends
on whether the entire procurement process requires the document to be signed
or not.
What is
needed at the business level is infomation about whether someone actual has
aproved the document. On the other hand, to reference the signature gives you
problem with consistency and persistency. This can be solved by adding two
more fields in document reference: GaranteeStoragePeriode and Hashcode
(perhaps hashmethod as well).
Kama>> So, there's a problem with detached
signature?
I would
like to here more about your requirements.
-----Oprindelig
meddelelse-----
Fra: Kama,
Kamarudin Bin Tambi [mailto:kama@crimsonlogic.com]
Sendt: 29. september 2005
09:02
Til:
ubl-tsc@lists.oasis-open.org; ubl-psc@lists.oasis-open.org; Peter Larsen
Borresen
Cc: Grace Ng, Swee
Lee (T&L); Jern Kuan, Leong; Fu Wang, Thio
Emne: RE: [ubl-tsc] [Fwd: [ubl-psc]
Proposal for a signature refenrence]
Hi
Peter, Tim,
Sorry
for the late response. We have reviewed the proposal for signature
reference. Below is our comment:-
1.
The signature
reference calls for the usage of detached signature. This would be useful in
scenario where binary data is involved and where the referenced signature is
always available and accessible via the specified URL
2.
Both ebXML
messaging service and COML however uses the enveloped approach, wherein the
digital signature (digsig) is embedded inside the message itself. In the
case of COML, XPath is being used to reference the appropriate section of
the payload that needs the digsig. This is a preferred approach where we
need to perform online verification of digsig. Hence, there will not be a
need to make reference to an external resource, which may not be available
at the time when the digsig verification is being performed. This reduces
the possibility of digsig failure.
We
would urge that you study the COML approach in handling digsig for XML
payload.
Regards
Kama
UBL
TSC Chair
-----Original
Message-----
From: Tim
McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, September 13, 2005 9:06
PM
To:
ubl-tsc@lists.oasis-open.org
Subject: [ubl-tsc] [Fwd: [ubl-psc]
Proposal for a signature refenrence]
forwarded from Peter
Borresen.
this is a sample isnatcen of his propsoed digital
signature approach. can we get some technical feedback on the
suitability of this for our needs.