RE: ebxml packaging and transport conference call

[David Burdett <david.burdett@commerceone.com>]

Juan Carlos

Having read your fuller description below. I find I agree with you
completely, so I have added in section 2, Reliable Messaging and Error
Handling a new item 5 as follows ...

"5) There must be method by which a secure acknowledgement of the receipt of
a signed message can be generated and sent back to the sender of the
original message"

Does this answer your point?

Regards

David

-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
Sent: Friday, December 03, 1999 9:18 AM
To: David Burdett; 'Juan Carlos Cruellas'; Rik Drummond
Cc: ebXML-Transport@lists.oasis-open.org
Subject: RE: ebxml packaging and transport conference call


At 09:43 01/12/99 -0800, David Burdett wrote:
Hi,

As I told Rik, it was not possible for me to join the meeting 
December the 2ond because I was in Madrid in a conference.


I make comments to the comments of David below on the point
it seems we have some different views marked with #JC# . 

>Juan
>
>I think there must have been some mix up on the date as it was just Rik and
>I on the call this morning at 8AM Pacific Standard Time, which we abandoned
>after about 10 minutes.
>
>I've also made some comments on your suggestions below, marked with a ##
...
>
>David
>
>-----Original Message-----
>From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
>Sent: Wednesday, December 01, 1999 9:44 AM
>To: Rik Drummond
>Cc: ebXML-Transport@lists.oasis-open.org
>Subject: Re: ebxml packaging and transport conference call
>
>
>At 13:36 30/11/99 -0600, you wrote:
>Rik,
>
>I have  realized just now that you have fixed the conference call for
>December 2...
>As I told you I am not able to attend the meeting as I will be in a
>conference tomorrow....
>I initially thougth that you had changed the date of the meeting, but I see
>now that
>you haven't, probably because it is more suitable the 2ond for other
people.
>Anyway, perhaps you can send me an email summarising the discussion. 
>As for me, I am specially interested in security, and there is a couple of
>things
>that I have to comment:
>
>1. In the document circulated in the list by David, and under the Security
>topic, appear 
>requirements on signatures and confidentiality, but nothing is said on
>secure acknowledge
>of reception and non repudiation of receipt. I am talking about something
>that it is 
>a real requirement in business process:  the
>sender of a signed document wants to receive a signed document by the
>receiver saying
>that he has received the document he sent, and he wants to receive
>something that can
>demonstrate that indeed the document was received by the recipient
>##
>I agrere so under the security section I have added another bullet numbered
>"1.d" that says ...
>"d) Signatures on digitally signed documents can be used to:
>	i) verify the authenticity of the sender, and
>	ii) provide a digitally signed acknowledgment of the receipt of a
>document"
>
>Does this meet your requirement?
>##
#JC#
I agree
##
> As I said, this is a real requirement: in Spain we have set up a pilot on
>use
>of EDI on internet among EANCOM users, and the  first thing they put on the
>table was
>that they wanted to have something demonstrating that the message had
>reached the
>recipient. In EDIFACT a special message has been defined for this purpose,
>the 
>AUTACK message, that contains references to the messages received and
>digital
>signatures of these messages, which provides to the sender with a proof of
>that
>the recipient actually received the message. I think that some similar
>development
>is needed in XML/EDI: a message, with a defined structure so that the
>non-repudiation
>of receipt is provided in the same way always. 
>##
>I think there is a difference between:
>1. The ability to digitally sign documents in a message sent over the net,
>and
>2. What the digital signature **means**.
>
>The first point I think is within scope in that we need to be able to
>provide the structures required, but I think the second is out of scope
>since it is an attribute of the certificate used to digitally sign the
>document. To take a slightly crazy example, suppose, someone used a
personal
>digital certificate designed to be used to support the SET payment protocol
>and then used it to digitally sign an acknowledgement of a Purchase Order
>what does it mean? It's clearly an abuse of the use of the SET certificate
>and therefore any assertions about "non-repudiation" are meaningless. I
>therfore think that actual "non-repudiation" is out of scope for our work
>although we facilitate it happening.
>##

#JC#
I agree in that there is a difference between the two points you are
mentioning. 
>From what I have read from your comments, I am not very sure of
having explained my point correctly. 
My point is, shortly speaking, that we should provide dtds establishing
how a secure acknowledgement of a signed message received 
should be done in XML/EDI, just as AUTACK message
in EDIFACT is doing: its use is clear in its intentions, it provides secure
acknowledge
by containing signatures on that signed messages arrived. 
Of course, this will serve as non-repudiation only if the private key used
to 
sign is the one that has to be used there, as happens with the signature
in the arrived message, but this is general: in order to conclude that
a security service has been correctly applied the correctness of the
cryptographic results and the cryptographic material (keys used,
validity of certificates, etc.)  have to be checked, and I think that
even saying that we should not consider "meanings" of the digital
signatures,
we should take into account that there is a need for a signed message sent
in
answer to another as a secure acknowledgment, and that we should provide
a specific syntax solution for it. In fact it is not so far from one of the
requirements,
because it would be a digital signature of other document, only that
computed
as a way of acknowledge that one has received a secure message, and at the 
same time, to provide the sender with technical means to counter a risk: the

denial of having received that message... 

My question is, do we agree in looking if there is a specific and well
defined 
way of doing that? and if not, do we agree in providing one?

 #JC#

>2. On my contribution to the work of the group, I would like to focus on
>security issues mainly. 
>In this way, I think that we should start by doing two things:
>
>	a. Agreeing in the security services we would like to see in the
>XML/EDI
>messages.
>##
>Agreed.
>##
>	b. As it seems that the other thing we should do is to carry out a
>review of 
>	existing security standards, we should agree in a structure of the
>review
>documents, 
>	in terms of producing something coherent that facilitates
>comparisons and
>summaries,
>	and not get a set of documents completelly different....
>
>	b. Reviewing existing security services and infrastructures
>documents and
>standards.
>	I put on the table the parts 5, 6, 7 and 9 of ISO9735 (EDIFACT
>syntax),
>and I can
>	commit myself to provide a reviewing document on them, but I can
>also
>participate in 
>	the review of other security standards and documents (PKCS, OFTP,
>W3Consortium
>	document on digital signatures, S-MIME, PKI documents, etc.).
>##
>... and I'll do a review of the W3C/IETF working group work and also of
>S-MIME.
>##
>I think that we should arrive in the February meeting with this document
>produced and a 
>decision taken on what our activity in the security field should be
>afterwards (whether we
>will produce additional specifications for other services, etc.)
>
>Regards.
>
>Juan Carlos.
>
>>ebxml conference call for packaging and transport wg on December 2, 1999
at
>>8:00 pacific standard time for one hour at most.
>>
>>phone number: 212 293-3102 USA
>>
>>Rik
>>
>>
>
>