OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: ebxml packaging and transport conference call


That sounds fair enough.


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
>-----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';
>Subject: RE: ebxml packaging and transport conference call
>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 
>At 09:21 AM 12/10/1999 -0800, David Burdett wrote:
>>See comments below marked with ## ...
>>-----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
>>Sent: Wednesday, December 08, 1999 3:04 PM
>>To: David Burdett
>>Cc: 'Juan Carlos Cruellas'; Rik Drummond;
>>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
>>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
>>## 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,
>>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
>>>a signed message can be generated and sent back to the sender of the
>>>original message"
>>>Does this answer your point?
>>>-----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:
>>>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# .
>>>>I think there must have been some mix up on the date as it was just Rik
>>>>I on the call this morning at 8AM Pacific Standard Time, which we
>>>>after about 10 minutes.
>>>>I've also made some comments on your suggestions below, marked with a ##
>>>>-----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:
>>>>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
>>>>now that
>>>>you haven't, probably because it is more suitable the 2ond for other
>>>>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
>>>>that I have to comment:
>>>>1. In the document circulated in the list by David, and under the
>>>>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
>>>>"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
>>>>Does this meet your requirement?
>>>I agree
>>>> As I said, this is a real requirement: in Spain we have set up a pilot
>>>>of EDI on internet among EANCOM users, and the  first thing they put on
>>>>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
>>>>AUTACK message, that contains references to the messages received and
>>>>signatures of these messages, which provides to the sender with a proof
>>>>the recipient actually received the message. I think that some similar
>>>>is needed in XML/EDI: a message, with a defined structure so that the
>>>>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
>>>>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
>>>>digital certificate designed to be used to support the SET payment
>>>>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
>>>>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.
>>>I agree in that there is a difference between the two points you are
>>>>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
>>>by containing signatures on that signed messages arrived.
>>>Of course, this will serve as non-repudiation only if the private key used
>>>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
>>>we should take into account that there is a need for a signed message sent
>>>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
>>>because it would be a digital signature of other document, only that
>>>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:
>>>denial of having received that message...
>>>My question is, do we agree in looking if there is a specific and well
>>>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
>>>>      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
>>>>      in terms of producing something coherent that facilitates
>>>>comparisons and
>>>>      and not get a set of documents completelly different....
>>>>      b. Reviewing existing security services and infrastructures
>>>>documents and
>>>>      I put on the table the parts 5, 6, 7 and 9 of ISO9735 (EDIFACT
>>>>and I can
>>>>      commit myself to provide a reviewing document on them, but I can
>>>>participate in
>>>>      the review of other security standards and documents (PKCS, OFTP,
>>>>      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
>>>>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.)
>>>>Juan Carlos.
>>>>>ebxml conference call for packaging and transport wg on December 2, 1999
>>>>>8:00 pacific standard time for one hour at most.
>>>>>phone number: 212 293-3102 USA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC