RE: ebxml packaging and transport conference call

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

At 08:33 07/12/99 -0800, David Burdett wrote:
David,

It does. Thank you .

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