RE: ebxml packaging and transport conference call

[Henry Lowe <hlowe@omg.org>]

David,

That sounds fair enough.

Henry

PS: you may note that I've taken myself of the CC list as 
I've been getting two and three copies of some messages.
As we are all on the ebxml-transport list, is that sufficient?
--------------
At 10:49 AM 12/10/1999 -0800, David Burdett wrote:
>>>>requirements are supposed to be implementation independent.<<<
>
>A good point,  so I've included the following in section 2 Reliable
>Messaging and Error Handling.
>
>6) Support must be provided that enables the sending of messages to be
>non-repudiatable
>
>David
>-----Original Message-----
>From: Henry Lowe [mailto:hlowe@omg.org]
>Sent: Friday, December 10, 1999 10:39 AM
>To: David Burdett
>Cc: 'Rik Drummond'; 'Juan Carlos Cruellas';
>ebXML-Transport@lists.oasis-open.org
>Subject: RE: ebxml packaging and transport conference call
>
>
>David,
>
>The requirements I can agree with as below.
>
>On the certificates thing, as I'm not a sucurity guru, I don't 
>want to go any further without advice from our security folk. 
>There may be other ways to meet the requirement other than 
>with certificates -- requirements are supposed to be implementation 
>independent.
>
>Henry
>-----------------------
>At 09:21 AM 12/10/1999 -0800, David Burdett wrote:
>>See comments below marked with ## ...
>>
>>David
>>
>>-----Original Message-----
>>From: Rik Drummond [mailto:drummond@onramp.net]
>>Sent: Thursday, December 09, 1999 6:30 AM
>>To: Henry Lowe; David Burdett
>>Cc: 'Juan Carlos Cruellas'; ebXML-Transport@lists.oasis-open.org
>>Subject: RE: ebxml packaging and transport conference call
>>
>>
>>I agree.
>>
>>-----Original Message-----
>>From: owner-ebxml-transport@lists.oasis-open.org
>>[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Henry
>>Lowe
>>Sent: Wednesday, December 08, 1999 3:04 PM
>>To: David Burdett
>>Cc: 'Juan Carlos Cruellas'; Rik Drummond;
>>ebXML-Transport@lists.oasis-open.org
>>Subject: RE: ebxml packaging and transport conference call
>>
>>
>>Juan Carlos and David,
>>
>>What Juan Carlos (well, the Spanish EANCOM users) is asking for is
>>non-repudiation as well as an assurance the message arrived.  I don't
>>see why that should be out of scope.  Non-repudiation is a well
>>understood service and is offered by a number of transports, including
>>CORBA, as part of their security service.  For some commercial
>>services, it's probably necessary -- although it is does make the
>>implementation/product more heavy weight.  But, in commercial
>>applications where this is necessary, people are probably willing
>>to pay the price.
>>
>>##Henry. In many ways I agree with you. Perhaps I've been following the
>>IETF/W3C dsig stuff for too long but there is an argument that goes along
>>the lines of, if someone gets unauthorized access to your digital
>>certificates then they can pretend to be you. This means that someone else
>>could get a message that appears to be from you even if it actually isn't.
>>This is what I meant in an earlier email when I was talking about the
>>importance of trust hierarchies and maintaining certificates in a secure
>>place which I think should both be out-of-scope. So how about including
>>something along the lines of ...
>>
>>"Support must be provided that enables the sending of messages to be
>>non-repudiatable"
>>
>>Would this meet your need?
>>
>>##
>>
>>The second thing, which came to mind in reading the message below,
>>is that, while not stated explicitly, there may be a requirement
>>for delivering a message once-and-once-only (e.g., you don't want
>>to send someone an electronic bank draft for one million Euros
>>twice because of some transmission error).  For this, you really
>>and a transport which offers once-and-once-only semantics (these
>>are usually based on two phase commit and there are a number of
>>them, the oldest probably being IBM's CICS but there are also
>>BEA's TUXEDO and CORBA's OTS).
>>
>>## Currently in section 1 Reliable Messaging and Error Handling, it says
>...
>>
>>1) Documents must be capable of being sent to another party so that:
>>a) delivery occurs once and only once
>>b) ... 
>>
>>Does this cover your point?
>>##
>>Best regards,
>>Henry
>>-------------------------------------
>>At 08:33 AM 12/07/1999 -0800, David Burdett wrote:
>>>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
>>>>>
>>>>>
>>>>
>>>>
>>